upright partial differential
Will Robertson
Some baby steps happening in unicode-math at the moment while I have a
small break from my thesis.
Does anyone know the official status of "U+2202: partial differential"
and "U+1D715: mathematical italic partial differential" ?
In STIX and Cambria Math they look identical (and italic), but there
are a few references around the web on how partial differentials are
often typeset upright. Furthermore, there is a bold upright and a bold
italic version.
I guess this makes things easier for me, really. If 2202 and 1D715 are
indeed identical, I don't need to provide a user interface to switch
between them. A couple of open-ended questions though:
1. If they are identical, then it's very odd that 1D715 is included
in unicode at all.
2. I'd like to normalise the input so you don't end up with different
glyphs in the output (even if they do look the same), so which one
should I use? I guess 2202 is the safer option.
Will
Will Robertson
> in my opinion it should be possible to have a distinction between
> upright partial and italic partial to satisfy the requirements of
> physics.
>
> If U+1D715 is designated as the italic version of partial, I conclude
> that U+2202 should contain the upright version. If both slots contain
> the same symbol (as in CambriaMath), this might well be considered
> a bug of the font.
>
> For the unicode-math LaTeX package, I'd prefer to keep the logical
> distinction between the two slots, even if no fonts currently
> support it.
>
> Hopefully, future developments in math fonts will be doing better.
> I have recently seen a font sample of Minion Math by Johannes Küster
> which does indeed have an upright partial at U+2202 as it should be,
> so there are fonts in the making, which will eventually support it.
Hi Ulrik,
Thanks for the comments; I'll take your advice.
Apostoulos, are you still around here and listening? :)
Will
Barbara Beeton
small break from my thesis.
Does anyone know the official status of "U+2202: partial differential" and
"U+1D715: mathematical italic partial differential" ?
it's my understanding that U+2022 is assumed
to be upright; otherwise there would be no
need for an explicitly italic one.
the unicode book shows both the same. i'll
call this to their attention.
In STIX and Cambria Math they look identical (and italic), but there are
a few references around the web on how partial differentials are often
typeset upright. Furthermore, there is a bold upright and a bold italic
version.
I guess this makes things easier for me, really. If 2202 and 1D715 are
indeed identical, I don't need to provide a user interface to switch
between them. A couple of open-ended questions though:
1. If they are identical, then it's very odd that 1D715 is included in
unicode at all.
2. I'd like to normalise the input so you don't end up with different
glyphs in the output (even if they do look the same), so which one should I
use? I guess 2202 is the safer option.
i think this is going to become a problem.
clearly the unicode committee slipped a bit
on this one. since the ascii latin and
greek alphabets were assumed to be upright
lightface, when the alternate form of the
partial was added to the math alphabets
in plane 1, it seems that nobody paid
attention to the fact that all the charts
showed the partial at 2022 to be italic.
(the holes in the rest of the math italic
alphabet in plane 1 do attest to the fact
that some letters are explicitly defined
in the 20xx block.) my guess is that 2022
is what most people are going to use, and
that will short-circuit the intention.
and clearly it slipped by me when i was
vetting the stix font. oops!
-- bb
Joel C. Salomon
> Does anyone know the official status of "U+2202: partial differential"
> and "U+1D715: mathematical italic partial differential" ?
Of possible interest: On math-font-discuss, back in 1997, there was a
discussion about the upright partial differential symbol, archived at
<http://www.tug.org/twg/mfg/mail-html/1997-03/msg00018.html>. Seems
some physics standards (ISO something-or-other) require all operators to
be upright, including the differential d & \partial.
> 2. I'd like to normalise the input so you don't end up with different
> glyphs in the output (even if they do look the same), so which one
> should I use? I guess 2202 is the safer option.
Depends on whether you’re mapping letters, e.g., $x$ to italic but $X$
to upright, or not. In “raw” mode ($x$ → upright; $𝑥$ → italic) it’s
easy; in the mapping modes U+2022 ∂ is the more likely input and should
map to the math italic (U+1xxxx) in “US” mode or to the (possibly)
upright (U+2022) in “ISO” mode. (And \partial should behave the same?)
—Joel Salomon
Ross Moore
On 15/09/2009, at 4:11 AM, Joel C. Salomon wrote:
>
> Will Robertson wrote:
>> Does anyone know the official status of "U+2202: partial
>> differential"
>> and "U+1D715: mathematical italic partial differential" ?
>
> Of possible interest: On math-font-discuss, back in 1997, there was a
> discussion about the upright partial differential symbol, archived at
> <http://www.tug.org/twg/mfg/mail-html/1997-03/msg00018.html>. Seems
> some physics standards (ISO something-or-other) require all
> operators to
> be upright, including the differential d & \partial.
I'd agree with this.
The differential operators should be upright, though it
is soooo common to see them slanted --- especially the dx
at the end of an integral.
To me this is laziness on the part of the author, since he/she
just wants to simply type 'dx' rather than bother with defining
macros and type extra keystrokes.
>
>> 2. I'd like to normalise the input so you don't end up with
>> different
>> glyphs in the output (even if they do look the same), so which one
>> should I use? I guess 2202 is the safer option.
>
> Depends on whether you’re mapping letters, e.g., $x$ to italic but
> $X$
> to upright, or not. In “raw” mode ($x$ → upright; $𝑥$ →
> italic) it’s
> easy;
Not sure exactly what you mean by “raw” mode here.
Most people will be typing LaTeX input on the keyboard and expect
$x$ to give italic.
Typing $𝑥$ directly just won't happen as keystrokes.
However, this *will* happen when using copy/paste from properly
formed mathematical source (e.g. from a PDF using Unicode
fonts or correct CMap resources). In fact one would have to wonder
whether the $...$ are actually needed; that is, an author would be
very tempted to just copy/paste a large chunk of text with inline
math, and just not bother with the delimiters. Would they notice
that the spacing is a bit wrong?
If they *do* go back to insert $...$ by hand, then what is the
input mode? How do you implement the distinction that would
cause $x$ → upright ?
It should be very difficult to produce an upright isolated 'x'
within math mode. The whole purpose of math-italic was to create
a distinction from normal text, and this should be preserved.
> in the mapping modes U+2022 ∂ is the more likely input and should
> map to the math italic (U+1xxxx) in “US” mode or to the (possibly)
> upright (U+2022) in “ISO” mode.
Most uses of ∂ are based upon the operator meaning --- not necessarily
"partial derivative", but also the homology "boundary" operator.
So surely the expected result would normally be the upright form.
Similar to above, it should be difficult to get an italic ∂ ,
unless that is what the chosen font puts at U+2022 .
> (And \partial should behave the same?)
Agreed, as this is the macro name that is well-known and exists
extensively in the (sources of) math literature.
These are just my views, as a mathematician who has to deal with
other people's (generally badly written) manuscripts.
I am of the view that future input methods should be actively
encouraging people to produce good mathematical notation, not simply
providing equal access to all the math letters that Unicode now
gives access to.
>
> —Joel Salomon
Cheers,
Ross
------------------------------------------------------------------------
Ross Moore ro...@maths.mq.edu.au
Mathematics Department office: E7A-419
Macquarie University tel: +61 (0)2 9850 8955
Sydney, Australia 2109 fax: +61 (0)2 9850 8114
------------------------------------------------------------------------
ulrik...@arcor.de
> Of possible interest: On math-font-discuss, back in 1997, there was a
> discussion about the upright partial differential symbol, archived at
> <http://www.tug.org/twg/mfg/mail-html/1997-03/msg00018.html>.
Oh dear, it's been 12 years since we started to discuss these issues,
an it is still the same people involved in the discussion. ;-)
> Seems some physics standards (ISO something-or-other) require
> all operators to be upright, including the differential d & \partial.
Yes, right. This is indeed the case. It is specified like this by the
guidebooks of IUPAP and IUPAC for physics and phyisical chemistry.
I presume the basic ideas are largely the same as in ISO 31-10,
although I do not have access to the ISO standard documents myself.
For additional references, I can point you to the following links:
* an upublished discussion paper of mine from 1997:
http://www.tug.org/twg/mfg/papers/ulrik/physreq.pdf
* a recent EuroTeX paper of mine (to be published in MAPS and TUGboat):
http://www.tug.org/~vieth/papers/eurotex2009/physmath-paper.pdf
* an older version of the IUPAC guidebook for physical chemistry:
http://www.iupac.org/publications/books/gbook/green_book_2ed.pdf
(see pp. 89 ff for mathematical notation)
* an unofficial revision of the IUPAP guidebook for physics:
http://www-v2.sp.se/metrology/IUPAP_SUNAMCO/IUPAP%20SUNAMCO%20Commission_files/IUPAP_Red_book_1987/SUNAMCO%20Red%20book%201987/index_red_book_iupap_sunamco_1987.htm
http://www-v2.sp.se/metrology/IUPAP_SUNAMCO/IUPAP%20SUNAMCO%20Commission_files/IUPAP_Red_book_1987/SUNAMCO%20Red%20book%201987/5_Symbols_Mathematical_iupap_sunamco_red_book_1987.pdf
(see chapter 5 for mathematical notation)
Note: The 1987 edition of the IUPAP guidebook unfortunately suffers
from somelimitations of TeX fonts, so it does show an italic partial,
unlike the 1978 edition, which was produced in the pre-TeX era.
On the other hand, the IUPAC handbook does show an upright partial.
Regards,
Ulrik Vieth
Joel C. Salomon
>> Of possible interest: On math-font-discuss, back in 1997, there was a
>> discussion about the upright partial differential symbol, archived at
>> <http://www.tug.org/twg/mfg/mail-html/1997-03/msg00018.html>. Seems
>> some physics standards (ISO something-or-other) require all
>> operators to
>> be upright, including the differential d & \partial.
>
> I'd agree with this.
> The differential operators should be upright, though it
> is soooo common to see them slanted --- especially the dx
> at the end of an integral.
>
> To me this is laziness on the part of the author, since he/she
> just wants to simply type 'dx' rather than bother with defining
> macros and type extra keystrokes.
Not sure I agree with you here. The choice of italic or upright for the
differential d is a matter more of taste and convention than laziness.
Looking through half a dozen textbooks I have handy, *none* use an
upright font for the differential d, or the capital D, or for e or π.
That said, there is still a need for a differential d macro to get the
spacing right in integrals. Guiggiani & Mori in TUGboat 29:2 suggest
(http://tug.org/TUGboat/Articles/tb29-2/tb92guiggiani.pdf)
\newcommand{\ud}{\mathop{}\!\mathrm{d}}
while Beccari in TUGboat 18:1 has a much more complicated invocation.
We might take a cue from the “Unicode Nearly Plain-Text Encoding of
Mathematics” (at <http://www.unicode.org/notes/tn28/>):
> 3.11 Differential, Exponential, and Imaginary Symbols
>
> Unicode contains a number of special double-struck math italic symbols
> that are useful for both typographical and semantic purposes. These
> are U+2145–U+2149 for double-struck D, d, e, i, and j (ⅅ, ⅆ, ⅇ, ⅈ, ⅉ),
> respectively. They have the meanings of differential, differential,
> natural exponent, imaginary unit, and imaginary unit, respectively.
>
> In US patent applications these characters should be rendered as ⅅ,
> ⅆ, ⅇ, ⅈ, ⅉ as defined, but in regular US technical publications, these
> quantities can be rendered as math italic. In European technical
> publications, they are sometimes rendered as upright characters.
> Furthermore the D and d start a differential expression and should
> have appropriate spacing for differentials. The linear format treats
> these symbols as operand characters, but the display routines should
> provide the appropriate glyphs and spacings. See Sec. 3.4 for an
> example of an integral using ⅆ.
(Section 3.4 shows the syntax
∫_0^a▒xⅆx/(x^2+a^2)
or, using the more easily typed equivalent form,
\int_0^a \of x\dd x/(x^2+a^2)
as producing the same effect as the LaTeX code
\int_0^a \frac{x \diffd x}{x^2 + a^2}
—assuming \diffd has been defined as d, upright or italic, as you
prefer, with the appropriate spacing.
(Actually, if one makes U+2146 ⅆ active you can have the XeLaTeX code
∫_0^a \frac{xⅆx}{x^2+a^2}
work the same way. Cool, huh?)
>>> I'd like to normalise the input so you don't end up with different
>>> glyphs in the output (even if they do look the same), so which one
>>> should I use? I guess 2202 is the safer option.
>>
>> Depends on whether you’re mapping letters […] or not.
>> In “raw” mode ($x$ → upright; $𝑥$ → italic) it’s easy;
>
> Not sure exactly what you mean by “raw” mode here.
> Most people will be typing LaTeX input on the keyboard and expect
> $x$ to give italic.
> Typing $𝑥$ directly just won't happen as keystrokes.
>
> However, this *will* happen when using copy/paste from properly
> formed mathematical source (e.g. from a PDF using Unicode
> fonts or correct CMap resources).
I’m positing the existence of a WYSIWYG math mode ($-delimited or no)
that will do only limited character mapping. As Ross suggests, this
will be used when pasting equations from a PDF file, e.g.
> In fact one would have to wonder whether the $...$ are actually
> needed; that is, an author would be very tempted to just copy/paste
> a large chunk of text with inline math, and just not bother with the
> delimiters. Would they notice that the spacing is a bit wrong?
>
> If they *do* go back to insert $...$ by hand, then what is the
> input mode? How do you implement the distinction that would
> cause $x$ → upright ?
>
> It should be very difficult to produce an upright isolated 'x'
> within math mode. The whole purpose of math-italic was to create
> a distinction from normal text, and this should be preserved.
If I’m doing copy-paste, I may be willing to insert the delimiting
$-signs, but I would not expect both $𝑥$ *and* $x$ to map to ‘𝑥’.
>> in the mapping modes U+2022 ∂ is the more likely input and should
>> map to the math italic (U+1D715) in “US” mode or to the (possibly)
>> upright (U+2202) in “ISO” mode.
>
> Most uses of ∂ are based upon the operator meaning --- not necessarily
> "partial derivative", but also the homology "boundary" operator.
> So surely the expected result would normally be the upright form.
>
> Similar to above, it should be difficult to get an italic ∂ ,
> unless that is what the chosen font puts at U+2022 .
Or if the house style calls for italicized differential operators.
If \diffd yields U+1D451 𝑑, then \partial should yield U+1D715 𝜕;
if \diffd yields U+0064 d, than \partial should yield U+2202 ∂;
\boundary (or whatever you name it) can yield U+2202 always.
> These are just my views, as a mathematician who has to deal with
> other people's (generally badly written) manuscripts.
> I am of the view that future input methods should be actively
> encouraging people to produce good mathematical notation, not simply
> providing equal access to all the math letters that Unicode now
> gives access to.
Default LaTeX math input is not going to be that future method; there’s
too much backward compatibility to be lost. (Remember the discussion
about what the colon should resolve to?) There’s still room to define
the input method of the future. Perhaps TN28 is a better starting point?
—Joel
ulrik...@arcor.de
> > just wants to simply type 'dx' rather than bother with defining
> > macros and type extra keystrokes.
Regarding lazyness, I have suggested a quick hack workaround
which consists of redefining the default math code of 'd' to upright,
so that typing 'dx' will automatically come out as upright-d italic-x.
(This works under the assumption that 'd' will almost always be
used as an operator and almost never as variable for distance.)
Unfortunately this trick doesn't work for upright-e and upright-i,
as the use of the letters 'e' and 'i' tends to be more mixed.
For a user interface, it would be nice to be able to specifiy
such things at the package level in unicode-math, e.g.
\usepackage[math-style=iso,d=upright,partial=upright,nabla=upright,Delta=upright]{unicode-math}
Once such a setup has been done at the beginning, it shouldn't be
the business of the author to care about upright 'd' or partial.
Regards,
Ulrik Vieth
Ross Moore
On 15/09/2009, at 8:33 AM, ulrik...@arcor.de wrote:
>
>>> To me this is laziness on the part of the author, since he/she
>>> just wants to simply type 'dx' rather than bother with defining
>>> macros and type extra keystrokes.
>
> Regarding lazyness, I have suggested a quick hack workaround
> which consists of redefining the default math code of 'd' to upright,
> so that typing 'dx' will automatically come out as upright-d italic-x.
> (This works under the assumption that 'd' will almost always be
> used as an operator and almost never as variable for distance.)
That would make it extremely difficult to get the normal italic 'd'
when you really want it.
A better macro might be to "look-ahead" at the next character.
If it is another letter (or macro expanding to an ordinary character)
then use a differential-d (whether upright or slanted) with appropriate
spacing. If a space, or a delimiter, etc. then expect the 'd' to be
a variable name, so is slanted.
An interesting case is when the 'd' is the beginning of a word,
such as a function name.
Mathematica does this well: when there is no space between letters
(in math-mode) then those letters are set upright, as a single word.
When there is a space, it is treated as an "implicit multiply"
generating a thin-space (as appropriate for math-spacing).
> Unfortunately this trick doesn't work for upright-e and upright-i,
> as the use of the letters 'e' and 'i' tends to be more mixed.
Not many house-styles use upright for these constants
--- myself included, actually ---
even though they (and I) probably should.
Even with look-ahead this would be very difficult to implement.
You would need an environment option to tell that the 'e'
and/or the 'i' are to have the economic and complex meanings.
>
> For a user interface, it would be nice to be able to specifiy
> such things at the package level in unicode-math, e.g.
>
> \usepackage[math-
> style=iso,d=upright,partial=upright,nabla=upright,Delta=upright]
> {unicode-math}
Such options are a good idea.
Also having options on individual environments would be useful.
>
> Once such a setup has been done at the beginning, it shouldn't be
> the business of the author to care about upright 'd' or partial.
I totally agree with this statement.
The author usually doesn't care, so wouldn't get it right anyway.
It has to be done using macros and options.
>
> Regards,
> Ulrik Vieth
Will Robertson
> On 15/09/2009, at 8:33 AM, ulrik...@arcor.de wrote:
>
>> Regarding lazyness, I have suggested a quick hack workaround
>> which consists of redefining the default math code of 'd' to upright,
>> so that typing 'dx' will automatically come out as upright-d italic-
>> x.
>> (This works under the assumption that 'd' will almost always be
>> used as an operator and almost never as variable for distance.)
>
> That would make it extremely difficult to get the normal italic 'd'
> when you really want it.
> A better macro might be to "look-ahead" at the next character.
> If it is another letter (or macro expanding to an ordinary character)
> then use a differential-d (whether upright or slanted) with
> appropriate
> spacing. If a space, or a delimiter, etc. then expect the 'd' to be
> a variable name, so is slanted.
I admire the intent but I don't think this would be very reliable. A
much better alternative, IMO, is to provide users with high-level
macros for inserting integrals and differentials such as provide by
the "cool" package. Such as
\Int{x(t)}{t,1,2} -> \int^2_1 x(t) \text{d}\,t
\D{x}{t} -> \frac{\text{d}x}{\text{d}t}
(although I disagree with the short names).
This would dramatically improve the usefulness of importing maths to
and from LaTeX syntax, as well. (E.g., Mathematica does an excellent
job exporting maths expressions to LaTeX, but only if you're happy
with its hard-coded typesetting conventions.)
> An interesting case is when the 'd' is the beginning of a word,
> such as a function name.
> Mathematica does this well: when there is no space between letters
> (in math-mode) then those letters are set upright, as a single word.
> When there is a space, it is treated as an "implicit multiply"
> generating a thin-space (as appropriate for math-spacing).
Morten has discussed something like this for breqn. Generally, I like
it, especially for things like
\int^x-1 -> \int^{x-1}
\int^x -1 -> \int^x-1
but again I wonder how robust it can be (considering spaces are always
skipped after control sequences) and whether users will find it more
of a hassle in the end.
>> For a user interface, it would be nice to be able to specifiy
>> such things at the package level in unicode-math, e.g.
>>
>> \usepackage[math-
>> style=iso,d=upright,partial=upright,nabla=upright,Delta=upright]
>> {unicode-math}
>
> Such options are a good idea.
I hadn't thought about Delta yet. That's a good idea. If you believe
that adding auto-upright d, e, and i are useful then I'll add features
for them as well.
> Also having options on individual environments would be useful.
The interface isn't there yet but I'm expecting to be able to do
things like this.
Will
Ross Moore
On 15/09/2009, at 8:13 AM, Joel C. Salomon wrote:
>>> in the mapping modes U+2022 ∂ is the more likely input and should
>>> map to the math italic (U+1D715) in “US” mode or to the
>>> (possibly)
>>> upright (U+2202) in “ISO” mode.
>>
>> Most uses of ∂ are based upon the operator meaning --- not
>> necessarily
>> "partial derivative", but also the homology "boundary" operator.
>> So surely the expected result would normally be the upright form.
>>
>> Similar to above, it should be difficult to get an italic ∂ ,
>> unless that is what the chosen font puts at U+2022 .
>
> Or if the house style calls for italicized differential operators.
> If \diffd yields U+1D451 𝑑, then \partial should yield U+1D715
> 𝜕;
> if \diffd yields U+0064 d, than \partial should yield U+2202 ∂;
> \boundary (or whatever you name it) can yield U+2202 always.
Hold on a minute.
Unicode is mean to encode the meaning, not the style.
So the code-point should be the same, independent of the
visual appearance, according to how the 𝑑 or d is being used,
and similarly for the ∂ or 𝜕 .
> Default LaTeX math input is not going to be that future method;
> there’s
> too much backward compatibility to be lost. (Remember the discussion
> about what the colon should resolve to?) There’s still room to
> define
> the input method of the future. Perhaps TN28 is a better starting
> point?
Yeah. I found this earlier this morning.
Before taking it as the new gospel, it'd be nice to hear
what the MathML 3 guys have to say about it.
>
> —Joel
Joel C. Salomon
> On 15/09/2009, at 8:13 AM, Joel C. Salomon wrote:
>> If \diffd yields U+1D451 𝑑, then \partial should yield U+1D715
>> 𝜕;
>> if \diffd yields U+0064 d, than \partial should yield U+2202 ∂;
>> \boundary (or whatever you name it) can yield U+2202 always.
>
> Hold on a minute.
>
> Unicode is mean to encode the meaning, not the style.
> So the code-point should be the same, independent of the
> visual appearance, according to how the 𝑑 or d is being used,
> and similarly for the ∂ or 𝜕 .
We’re working from the developer’s standpoint, to create a user
environment where the code-point *can* be the same, independent of the
visual appearance. But we need to access glyphs in a font, and those
will be at specific code-points.
On the other hand, maybe we can put a style-independent code-point in
the PDF’s /ActualText so copy-paste is again style-invariant.
>> Default LaTeX math input is not going to be that future method;
>> there’s too much backward compatibility to be lost. (Remember the
>> discussion about what the colon should resolve to?) There’s still
>> room to define the input method of the future.
>> the input method of the future.
>>
>> Perhaps TN28 is a better starting point?
>
> Yeah. I found this earlier this morning.
> Before taking it as the new gospel, it'd be nice to hear
> what the MathML 3 guys have to say about it.
The new version of MS Office uses TN28 for input. It’s really nice for
WYSIWYG editing of equations, and about as nice as TeX for linear code.
(The trade-off is that there is less use of braces for simple grouping,
but spaces can be meaningful.) I’d suggest that anyone looking to
implement a math input method give MS Office 2007 a real try.
—Joel
Chris Rowley
I had to google TN28: not immediately helpful but I finally arrived at
a familiar document.
I cannot speak for the LaTeX3 Team or TUG since most of them (pace
Will and Morten) have their ageing heads buried deep in the sand wrt
possible futures for math input/archiving. Thus anything about
LaTeX-maths should be decided by this group alone; if this has any
consequences for the LaTeX kernel then some of us can take that
forward
as appropriate.
Many of the MathML 3 guys are potentially interested in 'simple linear
input for simple math expressions' but they are far too busy getting a
reasonably correct and readable spec finished right now. Lots of
other groups I work with are very much concerned with this (see below
for XNQLM). I hope and believe that the spec says very little about
'input methods' and not very much about MML-editors (beyond quite
reasonable and liberal defintions of compliance). But maybe Ross had
a more specific question in mind?
So here are my personal ideas as of this week, based on many years
keeping my ears to the ground and evaluating what I hear. This
probably will not answer what you need to know, so keep asking!
1. UTN28 (the U is crucial here, no better name? maybe something with
`math' in it?) was invented for an input/editing view of the maths,
not
for file content/archiving. At a low-level, it is used by only one
application.
2. 8-bit LaTeX was, for our purpoes, not invented. In practice its
use
is largely for file content/archiving although 'real nerds' use it raw
for editing; the idea of 'input' is rather foreign to the LaTeX
community as they only know about uses where there is nothing but
itself going into the file.
3. Unicode-LaTeX-Maths (ULM?) has barely been invented yet (but there
are lots of good ideas around). Maybe it is time to decide what jobs
it will be invented to do; this might help determine how it needs to
interact with UTN28. Then write a tn* paper on this.
4. We now have a rapidly growing class of input (primarily) languages
that are LaTeX-like and sufficently similar (except some remove the
backslashes) that they can all be called Something Like XNQLM (X is
Not Quite LaTeX-Maths) and which I described recently as one example
of:
This is LaTeX, but not as we process it!
Currently these are probably all 8-bit (or even 7-bit) unless we
include UTN28 in this class (it is much less like standard LaTeX).
5. Thus, going boldly into suggestions/predictions, some thoughts and
questions.
a: In the worlds I inhabit daily there is an overwhelming demand to
preserve, codify and process XNQLM (probably the 7-bit version for USA
use) as the lingua franca of maths-everything: communication, editing,
archiving, semantic annotation, input, cooking, ... .
Here 'codify' means a reasonably formal statement of what the language
contains or maybe, to help the software engineers, a more formal
specification. (I know this is a gross over-simplification, but many
of
you have alrady heard too much from me on this subject.)
b: Since there may at some stage be an explosion in the use of
UTN28/(O)MML, UTN28 it should not be neglected by this group. Indeed,
its design principles and detailed decisions probably should have a
major influence on ULM. I remain silent beyond this since I am not
sure what is needed here or on priorities.
c: You are welcome to define YAMIL but you may be the only user: the
poularity of the many current systems is that they use (almost) boring
old 8-bit LaTeX as the input language.
d: An important principle of the LaTeX Team is to provide flexible and
extensible tools, not to dictate how to use them by, eg, 'making easy
only what I know is "right"'.
Current areas of concern on this list that are not covered in this
post:
why physicists are pedanticly obsessed with maths notation details;
'colon' (I once had three use-cases);
cut-and-paste (v difficult even when restricted to MML: does anyone
here know how clipbaord's work on any particular version of any
particular OS, let alone how applications interact with the OS's and/
or
their own private clipboards);
compatibility with Mathematica/Maple/Ma'sCAsystem/Apple/Banana/... ;
whether one can distinguish between style/meaning of a math symbol:
what is wrong with the Unicode Math chars (v long and boring);
my liking for most of the UTN28 magic;
the non-fixedness of UTN28 (Murray is not happy with it all), ... .
Apologies for bad typing.
Will Robertson
Thanks for sharing your thoughts.
On 16/09/2009, at 10:58 PM, Chris Rowley wrote:
> 5. Thus, going boldly into suggestions/predictions, some thoughts and
> questions.
>
> a: In the worlds I inhabit daily there is an overwhelming demand to
> preserve, codify and process XNQLM (probably the 7-bit version for USA
> use) as the lingua franca of maths-everything: communication, editing,
> archiving, semantic annotation, input, cooking, ... .
>
> Here 'codify' means a reasonably formal statement of what the language
> contains or maybe, to help the software engineers, a more formal
> specification. (I know this is a gross over-simplification, but many
> of you have alrady heard too much from me on this subject.)
>
> b: Since there may at some stage be an explosion in the use of
> UTN28/(O)MML, UTN28 it should not be neglected by this group. Indeed,
> its design principles and detailed decisions probably should have a
> major influence on ULM. I remain silent beyond this since I am not
> sure what is needed here or on priorities.
Aspects of UTN28 I like very much in that it simplifies the input
syntax necessary to type mathematics. A big drawback that I see with
it is that it has no way of extending itself; look at the example of
how to type a cases expression and the LaTeX alternative, to me,
becomes much more palatable.
My goals behind unicode-math in the beginning were simply to shoehorn
LaTeX support for unicode maths input and output. Simply replacing
all Greek letter names by their symbol helps tremendously in
readability. Being able to unambiguously write \mathbf with either
Latin or Green symbols is a boon for new users that get confused
between the difference between \mathbf and \bm.
Looking ahead, my main goal for maths and LaTeX is to simply make
things easier. My preferred style for writing mathematical documents
is using a markup language, so whatever LaTeX+breqn+unicode-math
evolves into is what I want to be dealing with. If it turns out to be
possible to adopt aspects of Murray's linear math system, then I'll
gladly do so.
From the point of view of interoperability and all that, I'm less
clear how future LaTeX math systems should work. Would it make more
sense to build a MathML renderer (or use ConTeXt's) and then simply
invent a system to transform LaTeX(-like) syntax into MathML? Or
should that simply be a parallel task?
Sorry I didn't address any of your comments specifically :)
Will
Chris Rowley
> Aspects of UTN28 I like very much in that it simplifies the input
> syntax necessary to type mathematics. A big drawback that I see with
> it is that it has no way of extending itself;
unextendable for all time. Also, if its principles are adopted more
widely then an extensible implementation can be made, then sell the
mechanism/idea back to MS.
> look at the example of
> how to type a cases expression and the LaTeX alternative, to me,
> becomes much more palatable.
(maybe there are other gaps, even in MML2.0).
> My goals behind unicode-math in the beginning were simply to shoehorn
> LaTeX support for unicode maths input and output.
> Simply replacing
> all Greek letter names by their symbol helps tremendously in
> readability.
guess.
But this immediately raises questions of how similar need be the glyph
you see on
the editor screen and the one you see after LaTeX (and a renderer) has
had its wicked way.
Worse: above it says 'the editor' but I have at least three editable
windows open right now and they use different fonts and ...
do all editors have to display the same glyph (where 'same' is
suitably defined?
> being able to unambiguously write \mathbf with either
> Latin or Greek symbols is a boon for new users that get confused
for \... :
but all would be editor-dependent (I guess): so again seeing the
glyphs (if you can
distinguish boldness in your editor(s)) would be even better.
> Looking ahead, my main goal for maths and LaTeX is to simply make
> things easier.
> My preferred style for writing mathematical documents
> is using a markup language,
'what you see as a direct result of your input' or 'the raw code
in the file (which you may or may not see as raw code'.
> so whatever LaTeX+breqn+unicode-math
> evolves into is what I want to be dealing with.
this is the word 'evolve' as it implies a process that happens
elsewhere. But we in this group are (possibly uniquely) the ones who
will drive any such change.
> If it turns out to be
> possible to adopt aspects of Murray's linear math system, then I'll
> gladly do so.
from elsewhere.
>
> From the point of view of interoperability and all that, I'm less
> clear how future LaTeX math systems should work.
> Would it make more
> sense to build a MathML renderer
'renderer' implies to me positioned glyphs, not loads of <>s.
> invent a system to transform LaTeX(-like) syntax into MathML?
definite need for them.
A more immediate and really useful task for this group would be to
analyse and categorise them
(at least the major ones) so that we can:
-- try to eliminate unnecessary conflicts and catalogue necessary
ones;
-- describe in some standardised way what they do (and thus maybe what
a 'really useful converter'
should do;
-- [there are many other things in this work programme that are not
directly relevant here).
> Or should that simply be a parallel task?
tasks.
> Sorry I didn't address any of your comments specifically :)
chris
Will Robertson
[Regarding "Murray's linear input"]
>> Aspects of UTN28 I like very much in that it simplifies the input
>> syntax necessary to type mathematics. A big drawback that I see with
>> it is that it has no way of extending itself;
> Problem or challenge? I do not think it is intended to be
> unextendable for all time. Also, if its principles are adopted more
> widely then an extensible implementation can be made, then sell the
> mechanism/idea back to MS.
>
>> look at the example of
>> how to type a cases expression and the LaTeX alternative, to me,
>> becomes much more palatable.
> Indeed: odd that this is not already in the langauge as it is in MML
> (maybe there are other gaps, even in MML2.0).
I don't think I made myself clear, exactly. Here is how to do a simple
case statement in Murray's linear math:
|x| = {█ (&x" if "x ≥ 0@−&x" if "x < 0)┤
Perhaps it's more clear split over two lines with some whitespace (not
sure if this is legal syntax, but I assume so):
|x| = {█ ( &x" if "x ≥ 0 @
−&x" if "x < 0 ) ┤
Now, sure, this is relatively simple to read, but one concern I have
is that it's difficult to type. (I'm assuming the unicode comes
through relatively well on your end.) "Stealing" a bunch of unicode
slots to invent a markup without escape chars or control words only
gets you so far in terms of the meaning you can express with it.
The linear math input works great at the old "type what you want to
see" approach we've been ridiculing WYSIWYG editors for for decades.
What it's not able to do (at all!) is abstract any of its concepts.
For example, if I like writing '|x|' and you prefer the
\DeclareMathOperator version '\abs x', linear math doesn't help us at
all.
But then we start getting into the "content maths" area that I've
already said I'm not ready to start thinking about :)
[Input matters:]
>> Simply replacing
>> all Greek letter names by their symbol helps tremendously in
>> readability.
> Of the input, I guess you mean. true for other symbols also, I
> guess.
> But this immediately raises questions of how similar need be the glyph
> you see on
> the editor screen and the one you see after LaTeX (and a renderer) has
> had its wicked way.
> Worse: above it says 'the editor' but I have at least three editable
> windows open right now and they use different fonts and ...
> do all editors have to display the same glyph (where 'same' is
> suitably defined?
This has been one of my goals, actually; anything that is similar
(alphanumerically) I attempt to normalise. So it doesn't matter if you
write "a" or the unicode math plane italic equivalent, you'll still
end up with the same output. Similarly for Greek letters, and also for
the transformations that happen when you enter \mathbf, for example.
Another way to say this is that I'm trying to be generous in the input
that is accepted so difference between editors and fonts and pasting
from arbitrary sources should most of the time not affect you
receiving the output you expect.
>> being able to unambiguously write \mathbf with either
>> Latin or Greek symbols is a boon for new users that get confused
>> between the difference between \mathbf and \bm.
> True but maybe there is an even better way to do this without any need
> for \... :
> but all would be editor-dependent (I guess): so again seeing the
> glyphs (if you can
> distinguish boldness in your editor(s)) would be even better.
It's easy to get support into TeXworks (etc.) such that typing
\mathbf{a} or \mbfupa will auto-complete (when hitting escape) to the
unicode bold math equivalent. But transforming alphabets isn't the
only sort of useful markup!
Will
Jonathan Kew
Not being a math author, I generally just lurk, but I'll add in a
comment for once...
IMO, this is a serious concern. The "linear math" idea is to
mathematics a bit like what wiki markup schemes are to document
structure. Works well for a certain range of material, but begins to
break down as you extend the scheme to cover more and more different
options. There (rapidly) comes a point where remembering the meaning
of assorted block glyphs is harder than recognizing mnemonic control
words. And of course typing such things requires a custom keyboard or
some kind of palette or other "pick-and-choose" UI .... in which case
the keyboard or UI could equally well generate \tex \control \words or
<tags/> & &entities; instead of things like ▧ ▋ ▃.
A math-oriented editor might display such controls (whatever their
underlying representation) as something "friendlier", but even at the
level of "raw text" editing, I don't see much benefit to the "linear
math" approach once you go beyond the very simplest expressions and
start assigning special meanings to arbitrary graphic symbols.
From a (La)TeX point of view, I think it would be interesting to
consider how math input might be simplified by adopting some of the
linear math ideas; and accepting literal Unicode characters as for the
thousands of individual symbols (for those who have convenient ways to
input them) is certainly a big step in that direction; but I would
discourage any ideas of replacing readable control words with
arbitrary blobs. That looks more like an implementation convenience
(parsing is easy if every "control token" is a unique codepoint!) than
something that really benefits authors or readers of the source.
JK
Will Robertson
> And of course typing such things requires a custom keyboard or
> some kind of palette or other "pick-and-choose" UI .... in which case
> the keyboard or UI could equally well generate \tex \control \words or
> <tags/> & &entities; instead of things like ▧ ▋ ▃.
Well said, I couldn't agree more.
Of course, in Microsoft Office and RichEdit (framework Murray uses to
build all this stuff) this is all usually abstracted behind some sort
of user interface -- and I see from Murray's blog recently (I suppose
I should follow it more closely) Word allows you to type \matrix
instead of the black square.
> From a (La)TeX point of view, I think it would be interesting to
> consider how math input might be simplified by adopting some of the
> linear math ideas; and accepting literal Unicode characters as for the
> thousands of individual symbols (for those who have convenient ways to
> input them) is certainly a big step in that direction; but I would
> discourage any ideas of replacing readable control words with
> arbitrary blobs.
Again, completely agree.
Whether it's "wise" to start adopting some of linear math's
conventions, such as writing a matrix with @ to separate rows, remains
to be seen but there's a lot of thought been put into making the
system as a whole easy to type. (Looking past the "blobs instead of
control words" aspect.) Not all of it translates directly into
something that's easily scannable by TeX macros (I know, I know,
Chris) but Morten's been playing around with some scanning ideas in
math mode that should help some of this.
--
Will
Torsten Bronger
Jonathan Kew writes:
> On 1 Oct 2009, at 07:52, Will Robertson wrote:
>
>> [...]
>>
>> I don't think I made myself clear, exactly. Here is how to do a
>> simple case statement in Murray's linear math:
>>
>> |x| = {█ (&x" if "x ≥ 0@−&x" if "x < 0)┤
>>
>> Perhaps it's more clear split over two lines with some whitespace
>> (not sure if this is legal syntax, but I assume so):
>>
>> |x| = {█ ( &x" if "x ≥ 0 @
>> −&x" if "x < 0 ) ┤
>>
>> Now, sure, this is relatively simple to read, but one concern I
>> have is that it's difficult to type.
The markup language can provide a fallback like Ӓ or \alpha.
Even if you assume that most people don't have a good input method
in their editors, this is no problem in my option. The worst case
would be just where LaTeX is now.
>> [...]
>
> [...]
>
> IMO, this is a serious concern. The "linear math" idea is to
> mathematics a bit like what wiki markup schemes are to document
> structure. Works well for a certain range of material, but begins
> to break down as you extend the scheme to cover more and more
> different options. There (rapidly) comes a point where remembering
> the meaning of assorted block glyphs is harder than recognizing
> mnemonic control words.
Math people are accustomed to a plethora of symbols anyway. ;-)
Well, there mustn't be dozens of them, and they shouldn't look too
similar on screen.
> [...]
>
> From a (La)TeX point of view, I think it would be interesting to
> consider how math input might be simplified by adopting some of
> the linear math ideas; and accepting literal Unicode characters as
> for the thousands of individual symbols (for those who have
> convenient ways to input them) is certainly a big step in that
> direction; but I would discourage any ideas of replacing readable
> control words with arbitrary blobs.
Curiously enough, you don't need many special characters (apart from
the obvious substitutions α, ∑, arrows etc) to cover 99% of all
math.
One year ago, I abandoned my favourite pet project: Bobcat. It also
has got a formula syntax
<http://bobcat.origo.ethz.ch/wiki/proposal_for_formula_syntax>,
which combines UTN28, LaTeX+AMSMath, and a little bit of
reStructuredText. I needed "blobs" only for \matrix and \vector,
the rest is visually obvious.
Of course, you will always find people who need math notation that
is only doable with PSTricks. But you shouldn't optimise for them.
My experience was that three things are so nice in UTN28 that I'd
like to see them in LaTeX as well:
* Unicode everywhere, at least for visually obvious counterparts
* (1 / 2) instead of \frac{1}{2} or -- shorter but worse -- \frac12.
The strict macroname--parameters ordering was misguided.
* All braces are stretchable by default (as in MathML). \left and
\right were misguided.
By the way, UTN28's rules of delimiting of sub/superscripts are very
cute but also very very incompatible with current LaTeX.
Regarding content math: I don't think that this is an important use
case. Experienced LaTeX users tend to overrate this in my opinion.
Presentational math is sufficient for virtually all authors. I say
this although I'm a big fan of semantic markup. But *within* a
formula, it's overkill I think.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: torsten...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com
Will Robertson
On 01/10/2009, at 11:52 PM, Torsten Bronger wrote:
> My experience was that three things are so nice in UTN28 that I'd
> like to see them in LaTeX as well:
>
> * Unicode everywhere, at least for visually obvious counterparts
Check :)
> * (1 / 2) instead of \frac{1}{2} or -- shorter but worse -- \frac12.
> The strict macroname--parameters ordering was misguided.
This is technically possible with TeX's \over but there are issues
with, e.g., knowing what size things in the numerator should be before
you realise that you're inside a fraction.
> * All braces are stretchable by default (as in MathML). \left and
> \right were misguided.
Will (hopefully) be part of breqn or one of its support packages.
> By the way, UTN28's rules of delimiting of sub/superscripts are very
> cute but also very very incompatible with current LaTeX.
Yes and no. *If* everything is unicode you could easily get away with
writing
\sum^n+1_i=1 x^-i
But macros are out of the question unless they're terminated somehow
(e.g., having to write "\alpha;" or "\alpha{}", which isn't very nice).
> Regarding content math: I don't think that this is an important use
> case. Experienced LaTeX users tend to overrate this in my opinion.
> Presentational math is sufficient for virtually all authors. I say
> this although I'm a big fan of semantic markup. But *within* a
> formula, it's overkill I think.
I'm certainly not advocating semantic markup where it makes it (much)
more inconvenient for the user to type the equation. And I'm firmly of
the position that unicode-math is all about getting the presentational
math side working properly.
With regards to semantic/content math, I'm thinking about macros like
\Int{\ln x}{x,0,\infty}
\Int{r\theta}{r,-1,1}{\theta,0,\pi}
which are much easier to type and read (IMO! even if you start using
unicode) and later customise than
\int_0^\infty \ln x \dee x
\int_0^\pi \int_{-1}^1 r\theta \dee r \dee \theta
The MathML approach of providing both means of input make it much more
suitable for converting maths into a LaTeX-ready form. Consider
Mathematica's LaTeX output -- it's all hard-wired to use specific
symbols and you need to use regexp if you'd prefer different output.
Using content math would at least allow you to paste in the equation
directly and customise them with document specification rather than
post-processing the Mma output.
--
Will
Ross Moore
On 01/10/2009, at 10:35 PM, Will Robertson wrote:
>
> On 01/10/2009, at 6:28 PM, Jonathan Kew wrote:
>
>> And of course typing such things requires a custom keyboard or
>> some kind of palette or other "pick-and-choose" UI .... in which case
>> the keyboard or UI could equally well generate \tex \control
>> \words or
>> <tags/> & &entities; instead of things like ▧ ▋ ▃.
>
> Well said, I couldn't agree more.
I'm in agreement with Jonathan, sort of.
> Of course, in Microsoft Office and RichEdit (framework Murray uses to
> build all this stuff) this is all usually abstracted behind some sort
> of user interface -- and I see from Murray's blog recently (I suppose
> I should follow it more closely) Word allows you to type \matrix
> instead of the black square.
Having this kind of syntax understandable by TeX is certainly doable
in TeX, but *only* with strict caveats.
* It cannot apply to all of TeX, since math-mode is used implicitly
in several other structures.
* Special sub-languages, such as UTN28 would be, *must* be strictly
delimited. That is, state where use of it begins, e.g. with an optional
argument such as:
\begin{equation}[UTN28]
....
\end{equation}
Implementation would require first reading to the end of the {equation}
to capture the complete contents. Next start a grouping, change catcodes
and macro definitions as necessary, rescan the captured tokens to
pick up
the new catcodes, then expand the resulting tokens to create a new
stream
of "traditional" TeX encoding of the mathematical formulas.
It is important that no actual typesetting be done until those
preliminary
preprocessing (or "interpretation") steps have taken place, otherwise
there
can not be much of a guarantee of the quality that will result, nor even
of whether the coding will actually work.
>
>> From a (La)TeX point of view, I think it would be interesting to
>> consider how math input might be simplified by adopting some of the
>> linear math ideas; and accepting literal Unicode characters as for
>> the
>> thousands of individual symbols (for those who have convenient
>> ways to
>> input them) is certainly a big step in that direction; but I would
>> discourage any ideas of replacing readable control words with
>> arbitrary blobs.
>
> Again, completely agree.
If the coding is properly encapsulated, as described above,
then I don't have an issue with this.
However, you cannot have user-defined macros that expand into UTN28
mixed in with traditional (La)TeX macros.
If you want UTN28, then that is what you use, properly delimited.
Otherwise you use traditional LaTeX. But don't try to mix them
else no-one can be expected to know what you really mean.
>
> Whether it's "wise" to start adopting some of linear math's
> conventions, such as writing a matrix with @ to separate rows, remains
> to be seen but there's a lot of thought been put into making the
> system as a whole easy to type.
The @ would be converted into \\ (or \cr or similar) during the
preprocessing phase. No macros would be allowed to expand producing
an @ with a different meaning, so it should be OK.
> (Looking past the "blobs instead of
> control words" aspect.) Not all of it translates directly into
> something that's easily scannable by TeX macros (I know, I know,
> Chris) but Morten's been playing around with some scanning ideas in
> math mode that should help some of this.
>
> --
> Will
Hope this helps,
Ross
------------------------------------------------------------------------
Ross Moore ro...@maths.mq.edu.au
Ross Moore
On 01/10/2009, at 11:52 PM, Torsten Bronger wrote:
>
> Hallöchen!
>
> Jonathan Kew writes:
>
>> On 1 Oct 2009, at 07:52, Will Robertson wrote:
>>
>>> [...]
>>>
>>> I don't think I made myself clear, exactly. Here is how to do a
>>> simple case statement in Murray's linear math:
>>>
>>> |x| = {█ (&x" if "x ≥ 0@−&x" if "x < 0)┤
>>>
>>> Perhaps it's more clear split over two lines with some whitespace
>>> (not sure if this is legal syntax, but I assume so):
>>>
>>> |x| = {█ ( &x" if "x ≥ 0 @
>>> −&x" if "x < 0 ) ┤
>>>
>>> Now, sure, this is relatively simple to read, but one concern I
>>> have is that it's difficult to type.
>
> The markup language can provide a fallback like Ӓ or \alpha.
> Even if you assume that most people don't have a good input method
> in their editors, this is no problem in my option. The worst case
> would be just where LaTeX is now.
I don't know what is your beef against LaTeX.
In my opinion, Knuth's programming of math in TeX is very
pragmatic and very good.
Other languages which claim that they try to "simplify"
the input are in fact severely limited in scope, since
the bracketing characters (braces and parentheses) tend
to be dangerously overloaded.
>> IMO, this is a serious concern. The "linear math" idea is to
>> mathematics a bit like what wiki markup schemes are to document
>> structure. Works well for a certain range of material, but begins
>> to break down as you extend the scheme to cover more and more
>> different options. There (rapidly) comes a point where remembering
>> the meaning of assorted block glyphs is harder than recognizing
>> mnemonic control words.
>
> Math people are accustomed to a plethora of symbols anyway. ;-)
They are accustomed to a plethora of symbols as objects with specific
meanings. They are *not* used to using many different kinds of symbols
to control layout and structure.
These are not things that they use when writing on a whiteboard,
so they don't translate easily to a linear stream of coding.
Most people don't know about displayed alignments other than
{eqnarray} --- yet those who do know about the AMSmath alignments
shun (quite rightly) {eqnarray} completely!
> Well, there mustn't be dozens of them, and they shouldn't look too
> similar on screen.
>
>> [...]
>>
>> From a (La)TeX point of view, I think it would be interesting to
>> consider how math input might be simplified by adopting some of
>> the linear math ideas; and accepting literal Unicode characters as
>> for the thousands of individual symbols (for those who have
>> convenient ways to input them) is certainly a big step in that
>> direction; but I would discourage any ideas of replacing readable
>> control words with arbitrary blobs.
>
> Curiously enough, you don't need many special characters (apart from
> the obvious substitutions α, ∑, arrows etc) to cover 99% of all
> math.
I'll interpret this as being perhaps accurate with regard to specifying
the content of expressions and equations. However it is certainly not
true with regard to laying them out both aesthetically and just so
that they can be read easily.
>
> One year ago, I abandoned my favourite pet project: Bobcat. It also
> has got a formula syntax
> <http://bobcat.origo.ethz.ch/wiki/proposal_for_formula_syntax>,
> which combines UTN28, LaTeX+AMSMath, and a little bit of
> reStructuredText. I needed "blobs" only for \matrix and \vector,
> the rest is visually obvious.
>
> Of course, you will always find people who need math notation that
> is only doable with PSTricks. But you shouldn't optimise for them.
>
> My experience was that three things are so nice in UTN28 that I'd
> like to see them in LaTeX as well:
>
> * Unicode everywhere, at least for visually obvious counterparts
>
> * (1 / 2) instead of \frac{1}{2} or -- shorter but worse -- \frac12.
> The strict macroname--parameters ordering was misguided.
I don't know what you mean by misguided here.
Stating first the concept, then the data that it applies to,
is a perfectly acceptable form of communication.
TeX has {... \over ... } and \frac probably uses this ultimately,
after having first decided just what should go into the numerator
and denominator.
You can always redefine \frac to go back to such an infix form
if you wish. But I don't see why you would ever want to do that.
This use of parentheses as delimiters, in ( 1 / 2 ) , is just
another example of overloading.
What if I want a bracketed (\frac{a}{b}) , e.g. to raise it
to a power? Would I need (( a / b )) ?
Or if (( ... )) has a meaning and I need to apply this to a fraction?
Now it'll be ((( a / b ))) ??
Which pair of parentheses that capture the fraction, and which the
special notation?
And what if I just want to see $(a/b)$ as TeX currently would typeset
this; that is, I don't want to see a vertical fraction.
What would my coding be then?
> * All braces are stretchable by default (as in MathML). \left and
> \right were misguided.
I'm not so sure about this.
It would depend on things like whether the stretchiness is
continuous or in discrete steps. Certainly I prefer discrete
steps, since otherwise you are likely to end up with different
sized parentheses within the same line of text containing some
inline expressions. That would look pretty awful.
> By the way, UTN28's rules of delimiting of sub/superscripts are very
> cute but also very very incompatible with current LaTeX.
If you capture everything and scan for constructions that are
well-defined and easily recognisable, then any consistent notation
can be made compatible with (La)TeX.
There is a speed cost in doing this, but that's not so important
as it used to be when computers were much slower that they are now.
> Regarding content math: I don't think that this is an important use
> case. Experienced LaTeX users tend to overrate this in my opinion.
> Presentational math is sufficient for virtually all authors. I say
> this although I'm a big fan of semantic markup. But *within* a
> formula, it's overkill I think.
>
> Tschö,
> Torsten.
>
> --
> Torsten Bronger, aquisgrana, europa vetus
> Jabber ID: torsten...@jabber.rwth-aachen.de
> or http://bronger-jmp.appspot.com
Hope this helps,
Ross
------------------------------------------------------------------------
Ross Moore ro...@maths.mq.edu.au
Torsten Bronger
Ross Moore writes:
> On 01/10/2009, at 11:52 PM, Torsten Bronger wrote:
>
>> Jonathan Kew writes:
>>
>>> On 1 Oct 2009, at 07:52, Will Robertson wrote:
>>>
>>>> [...]
>>>>
>>>> |x| = {█ ( &x" if "x ≥ 0 @
>>>> −&x" if "x < 0 ) ┤
>>>>
>>>> Now, sure, this is relatively simple to read, but one concern I
>>>> have is that it's difficult to type.
>>
>> The markup language can provide a fallback like Ӓ or
>> \alpha. Even if you assume that most people don't have a good
>> input method in their editors, this is no problem in my option.
>> The worst case would be just where LaTeX is now.
>
> I don't know what is your beef against LaTeX. In my opinion,
> Knuth's programming of math in TeX is very pragmatic and very
> good.
It's only about special symbols here like \alpha and
\sum, i.e. lossless substitution.
> [...]
>
>>> IMO, this is a serious concern. The "linear math" idea is to
>>> mathematics a bit like what wiki markup schemes are to document
>>> structure. Works well for a certain range of material, but begins
>>> to break down as you extend the scheme to cover more and more
>>> different options. There (rapidly) comes a point where remembering
>>> the meaning of assorted block glyphs is harder than recognizing
>>> mnemonic control words.
>>
>> Math people are accustomed to a plethora of symbols anyway. ;-)
>
> They are accustomed to a plethora of symbols as objects with
> specific meanings. They are *not* used to using many different
> kinds of symbols to control layout and structure.
But "matrix" or "vector" are very specific mathematical meanings,
just like "fraction" ./. or "grouping" (...).
As I said, you need only a few symbols anyway.
> [...]
>
> Most people don't know about displayed alignments other than
> {eqnarray} --- yet those who do know about the AMSmath alignments
> shun (quite rightly) {eqnarray} completely!
It's only secondary here, but see
http://groups.google.com/group/comp.text.tex/msg/da426f105fc577e0?dmode=source
> [...]
>
>> Curiously enough, you don't need many special characters (apart
>> from the obvious substitutions α, ∑, arrows etc) to cover 99% of
>> all math.
>
> I'll interpret this as being perhaps accurate with regard to
> specifying the content of expressions and equations. However it is
> certainly not true with regard to laying them out both
> aesthetically and just so that they can be read easily.
Absolutely true. But if you want to have everything properly
aligned and spaced, you need full control, which is very
complicated. This should be realised through another level of
syntax which is allowed to make the source code bloated. "Make
simple things simple and hard things possible".
Amongst my collegues and -- unfortunately -- amongst my conferences
with camera-ready submission, nobody cares about finetuning, so one
should not optimise this from my point of view. I agree that my
statistical basis is limited.
> [...]
>>
>> * (1 / 2) instead of \frac{1}{2} or -- shorter but worse -- \frac12.
>> The strict macroname--parameters ordering was misguided.
>
> I don't know what you mean by misguided here. Stating first the
> concept, then the data that it applies to, is a perfectly
> acceptable form of communication.
But it is verbose, and it is very different from the pen-and-paper
representation.
> [...]
>
> This use of parentheses as delimiters, in ( 1 / 2 ) , is just
> another example of overloading.
> What if I want a bracketed (\frac{a}{b}) , e.g. to raise it
> to a power? Would I need (( a / b )) ?
I think in UTN28, yes, but I haven't looked it up. But you needn't
do it like UTN28, you can also give {} LaTeX's semantics.
> Or if (( ... )) has a meaning and I need to apply this to a
> fraction? Now it'll be ((( a / b ))) ??
This is a "make hard things possible" case, or use LaTeX's {}.
> [...]
>
> And what if I just want to see $(a/b)$ as TeX currently would
> typeset this; that is, I don't want to see a vertical fraction.
> What would my coding be then?
In UTN28, I don't remember. But again, it needn't be UTN28. I used
// for the horizonal fraction bar, and there are probably other
ways, too.
>> * All braces are stretchable by default (as in MathML). \left
>> and \right were misguided.
>
> I'm not so sure about this.
>
> It would depend on things like whether the stretchiness is
> continuous or in discrete steps.
This is an implementation detail of the typesetting backend.
Additionally, explicit sizing of parentheses can be allowed with a
"make hard things possible" kind of syntax.
Chris Rowley
it?
chris
Chris Rowley
it?
chris
On Oct 1, 9:58 am, Jonathan Kew <jonat...@jfkew.plus.com> wrote:
Joel C. Salomon
> Ross Moore writes:
>> This use of parentheses as delimiters, in ( 1 / 2 ) , is just
>> another example of overloading.
>> What if I want a bracketed (\frac{a}{b}) , e.g. to raise it
>> to a power? Would I need (( a / b )) ?
>
> I think in UTN28, yes, but I haven't looked it up. But you needn't
> do it like UTN28, you can also give {} LaTeX's semantics.
Not so; and it’s here that UTN28 gets hairy. Parentheses will be
invisible if they are used for grouping, and there is another visual
indication of the grouping there, e.g,
a/(b+c)
will render like
\frac{a}{b+c}
(If you want \frac{a}{(b+c)}, type a/((b+c)).)
But when the parens are the only indication of the grouping, e.g.,
(a+b)^n
they will be visible.
Basically, UTN28 is a really clever input method for a WYSIWYG maths
system, less good for a TeX-like edit-compile-view system. It is,
however, a useful compendium of ideas for our use.
—Joel
Ross Moore
On 03/10/2009, at 5:43 AM, Chris Rowley wrote:
>
> My earlier reseponse to this seems to have got lots? Did anyone see
> it?
You mean on 27 September ?
I've been at a conference this past week, with very difficult
access to email --- no support for imap, pop, ssh, etc.
So reading it was put on hold, sorry.
Just doing so now.
>
> chris
Cheers,
Ross
------------------------------------------------------------------------
Ross Moore ro...@maths.mq.edu.au
Will Robertson
> My earlier reseponse to this seems to have got lost? Did anyone see
> it?
I don't see it anywhere (last message from you Sept 27, as Ross said);
is it possible to repost?
--
Will