[Prev][Next][Index][Thread]
small samples
FRon Whitney writes:
> Here are some more samples which involve embellishment of symbols. To
> clarify how semantical information might be attached, I've asked a
> couple of questions in the notes.
Pushing this approach too far really brings out the need to have extensibility
addressed. The concerns of having the ability to express semantics where
possible without tying down authors or the system is far better addressed
than trying to come up with a large collection of denoting different
"embellished" operators.
This is not a criticism of Ron's excellent examples --it's just an attempt to
point out that perhaps by postponing our efforts at extensibility we're
making more work for ourselves both now and later.
To illustrate:
Consider an author wishing to write a Legendre symbol legendre (p,q)
TeX:
${p \atop q}$
Of late, we have been discussing two entirely divergent possibilities for
encoding semantics--
a) A completely semantic markup (which I like most of us in this ERB think is
impossible however much we may want it)
and
b) Layout oriented markup made as unambiguous as possible --an approach which
in principle I favor
Though you could come up with other markup for the Legendre symbol and perhaps even
embellish it in some way to provide semantics hints, the extension mechanism
if present would make this and a plethora of other examples easy to handle:
To illustrate using TeX's extension mechanism:
\newcommand\legendre[2]{{#1\atop#2}}
We denote by $\legendre{p}{q}$ ...
>
> The aim is to have a set of examples for the case of `strip' notation
> (symbols on a baseline with slight deviation for embellishments
> and fractions). This leaves out matrices and commutative diagrams
> and aligned equations, but should cover a lot of notation. Again,
> the approach is `notational' because I have the feeling that most
> members of the ERB would rather approach things this way than through
> semantics. (We're talking about devising notation which can be
> rendered to various forms with semantical cues, rather than devising
> semantical structures and specifying how to render those.)
>
> -Ron
>
>
>
> ---------------------------------------------------------
> Item 9 / fonts
>
> TeX: {\bf R}, \mathbf R
>
> Wolfram: <b>R</b>
>
> MINSE:
> Display-List (S):
> Display-List (MS):
> ISO 12083: <bold>R</bold>
>
>
>
> Notes:
> 1. The first style shown for TeX accords with standard text font
> changing mechanisms, the second is the method used with AMSTeX
> (actually "\bold" is used rather than "\mathbf") and AMSLaTeX.
> "\mathbf" takes a single argument, and "\mathbf R^n" would embolden
> only the "R".
>
> 2. I believe Bruce spoke of using the standard HTML (text) font change
> syntax for the Wolfram Proposal, but I know he mentioned that the
> specification within display list format was yet to be put forward.
>
> 3. I think Robert and Neil's display list format would use
> "<mattribute>", but I'm not certain about this.
>
> 4. I do find the AMSTeX, unary prefix operator, style of notation
> most natural since it accords with other operator-style methods of
> embellishing objects. Can this be done in the Wolfram approach?
>
> In the case of changing fonts on operators, Neil has said he thinks
> that allowing prefix operators on operators and also asking our
> parsers to interpret the result automatically as another operator will
> unduly complicate our parsers. This would imply that authors would
> have to enter something like "<mo ...>&bold;+</mo>" if we had a
> prefix-style font-changing mechanism. The same argument must also
> apply to other prefix "embellishments" of operators.
>
> 5. Suppose for the moment we have a paper in which the author uses
> emboldening to indicate vectors. Suppose also that the style for
> indicating the reals and complexes is to embolden the "R" and "C".
> Through the course of the paper we have objects mentioned in a variety
> of spaces, with some algebra and subscripting involved in giving the
> dimensions of the spaces (e.g., in TeX, "\mathbf R^{k^2_i+k_i-1}").
> How do we envision type-theoretic information being attached to
> all the various kinds of vectors? (And we should assume, to be
> difficult, that, say, "v" is used to denote vectors from spaces of
> different dimension as the article progresses; i.e. "v" is a bound
> variable used for different purposes within the article.) Do we
> envision that our type-theoretic information will contain notation
> itself?
>
>
>
> ---------------------------------------------------------
> Item 10 / primes
>
> TeX: x', x^\prime, x^{\prime\prime}
>
> Wolfram:
> MINSE:
> Display-List (S):
> Display-List (MS):
> ISO 12083:
>
>
> Notes:
> 1. TeX has two forms of priming, but Spivak eschewed the "x'" when
> he felt he could not get it to work in all situations which might be
> natural (so for AMSTeX only the forms using "\prime" are allowed.
>
> 2. I don't know how other notations handle the prime or plan to
> handle it. A superscripted "*" might also present a similar `odd
> case' if we opt for the "x'" style (i.e. treating the prime as a
> character already raised and in a smaller size). I would vote myself
> for treating a prime as a superscript and entering it as such
> (granting that people might change the `look' themselves by defining a
> macro).
>
> 3. For concreteness, how might some person or program associate
> differentiation to priming within a paper?
>
>
> ---------------------------------------------------------
> Item 11 / overlines
>
> TeX: \overline s, \overline{s+t}
>
> Wolfram:
> MINSE:
> Display-List (S):
> Display-List (MS):
> ISO 12083: <overline>s</overline>,
> <overline>s+t</overline>
>
>
> Notes:
> 1. The `line' of the ISO overline can come in many styles (single,
> double, triple, dash, dot, bold, etc.). TeX has to stand on its head
> to get many of these. "\overline" and "\bar" are two related
> embellishment forms, the first `stretchy', the second not.
>
> 2. I'm uncertain as to how the Wolfram Proposal will handle these
> sorts of things. And how will something like an overline be related
> to other operators which are stretchy or not?
>
>
> ---------------------------------------------------------
> Item 12 / overbar with subscript
>
> TeX: \bar x_1
>
> Wolfram: x^^&bar;_1
>
> MINSE:
> Display-List (S): <mscript>
> <moverscript>x<mc>&bar;</moverscript>
> <mc><mc>1
> </mscript>
>
> Display-List (MS):
> ISO 12083: x<top>&bar;</top><inf>1</inf>
>
>
>
> Notes:
> 1. This is a simple example, but it brings up a couple of points.
> If the overbar signifies conjugation, it's probably most likely that
> the proper "expression" (and, in any case, a possible expression) is
> one signifying the conjugate of the object "x_1". In this case,
> the Wolfram expression `should' be "x_1^^&bar;" (because the nesting
> of the display schemata is then correct). I assume the visual display
> will then be hard to get right (which only means `to look as it would
> look with the TeX coding', not that the standard visual display is
> logically correct).
>
> 2. And generally, it appears that the nesting of the various display
> schemata in the WP requires that *some* linear interpretation be
> given for the entire set of embellishments added to a character. (This
> is analogous to the standard problem of being required to *write* a
> matrix in row- or column-major form, but wanting to interpret it
> in both ways.)
>
> Bruce had a discussion in the WP about how `scripts' would `appear'
> from display list format (he spoke of following down a nested sequence
> of script operators, etc.). I took this to mean a literal sense of
> appearance, but perhaps he meant it in such a way as to imply
> symmetrical `meaning' (so that neither the bar nor the subscripting
> operator in the example above truly assume precedence within the
> display list). I need clarification in this.
>
> 3. And as with prime notation, how would a person or software specify
> that barring is to be read as conjugation? Does it come to individual
> interpretational annotations (semantical markup embedded within the
> mathematical text) or a declaration outside the body of a paper?
--
Best Regards,
--raman
Adobe Systems Tel: 1 (415) 962 3945 (B-1 115)
Advanced Technology Group Fax: 1 (415) 962 6063
(E 1-160) 1585 Charleston Road Email: raman@adobe.com
Mountain View, CA 94039 -7900 raman@cs.cornell.edu
http://www-atg/People/Raman.html (Internal To Adobe)
http://www.cs.cornell.edu/Info/People/raman/raman.html (Cornell)
Disclaimer: The opinions expressed are my own and in no way should be taken
as representative of my employer, Adobe Systems Inc.
____________________________________________________________________________
Follow-Ups:
References: