argument not enclosed in curly braces not accepted
nageh
statement, which breaks in MathJax:
\sqrt\frac{3}{4}
Enclosing the argument in curly braces works:
\sqrt{\frac{3}{4}}
-nageh
Davide P. Cervone
and actual TeX. MathJax does not have the same idea of "macro" and
"primitive" or TeX's "mouth" and "stomach" that TeX does, and so
MathJax does require braces in a few locations that TeX doesn't.
Basically, a multi-token argument (such as \frac{3}{4}) must be
enclosed in braces in MathJax.
Davide
nageh
> Yes, this is one of the few significant differences between MathJax
> and actual TeX. MathJax does not have the same idea of "macro" and
> "primitive" or TeX's "mouth" and "stomach" that TeX does, and so
> MathJax does require braces in a few locations that TeX doesn't.
> Basically, a multi-token argument (such as \frac{3}{4}) must be
> enclosed in braces in MathJax.
standard (La)TeX. Is there anything you can do about it?
-nageh
nageh
> standard (La)TeX. Is there anything you can do about it?
argument commands such as \frac?
-nageh
Davide P. Cervone
(not sure how to define "standard", here). There are a number of
things that are legal in TeX that will not work well in MathJax,
particularly sloppy TeX usage. Personally, I consider this a sloppy
usage (though opinions will vary), and it is an edge case, not a
primary use case.
But if you post a request in the issue tracker at the MathJax GitHub
page (https://github.com/mathjax/MathJax/), it will be considered for
future action.
Davide
Paul Topping
language meant to be typed by humans, LaTeX has syntax rules that allow
braces to be omitted unless they are needed to make the parse
unambiguous. This is similar to programming languages' use of operator
precedence. While there must be limits to MathJax support for some LaTeX
features, I would think this kind of thing would be very easy to
accommodate.
Paul
Davide P. Cervone
needed and when they are not, in TeX those rules are esoteric and are
not at all clear from the syntax itself, as they have intimately to do
with the difference between a "primitive" control sequence and a
macro, and with the details of how TeX processes these in its "mouth"
and "stomach". Most TeX users do not know these details. Most will
not even know that there IS a difference between its mouth and
stomach, let alone what it is, and most will not know which control
sequences are macros and which are primitives without looking them
up. Even if they do, which ones are macros can change depending on
the packages you have loaded. For example, can you tell me (without
running TeX) which of the following expressions are legal in LaTeX,
for those that are, what the output will be (given the two definitions)?
\def\A{\sqrt x}
\def\B#1{(#1)}
$ \sqrt\frac{a}{b} $
$ \sqrt\sqrt{x} $
$ \sqrt \left(x+1\right) $
$ \sqrt x^2 $
$ \sqrt -x^2 $
$ x^\sqrt 2 $
$ x^\sqrt{2} $
$ \sqrt\A $
$ \sqrt\B{x} $
$ \B \frac{a}{b} $
$ \frac \sqrt{a} {b} $
$ \frac \frac{a}{b} {c} $
It turns out that only five of these will process without producing an
error message, and of those, only one will produce what one would
naturally expect it to. The fact that $\sqrt\frac{a}{b}$ is valid but
$\sqrt\sqrt{x}$ isn't is a quirk due to the details of the definition
of \frac, not to any obvious syntactic rules about when braces are
allowed.
The fact that the rules that control this are not obvious and well-
known by the TeX community is why I consider \sqrt\frac{a}{b} to be
sloppy because it takes advantage of quirks rather than clear rules,
and because it encourages mistakes like \sqrt\sqrt{x} when you don't
have detailed knowledge of the internals of TeX. (And the difference
between a macro and a primitive is not apparent from the control
sequence itself, but requires knowledge of the internal state of TeX
at the moment.)
The example of precedence of operators is a good one to consider.
While it is true that there are unambiguous rules, I still consider
x^x^2 to be sloppy, because it leads too easily to misunderstanding.
Is it (x^x)^2 or x^(x^2)? For standard mathematics, it turns out to
be the latter, but many people don't know that, and so it is good
practice to include the parentheses explicitly, and sloppy to leave
them out. (In fact, TeX will not ALLOW you to leave them out because
of this common misunderstanding.) Just because something is
unambiguous doesn't mean it isn't sloppy.
Consider another example: suppose your language allows you to write
"sin x" rather than "sin(x)", and that function apply is done at a
higher precedence than all other operations (e.g., "sin" is considered
a high-precedence unary operation). Then what do you get from "sin
x^2"? This will NOT mean sin(x^2) as it usually would in written
mathematics, but rather (sin x)^2. On the other hand, sin -x^2
actually WOULD mean sin(-x^2), since powers are done before negation
(that is, -x^2 means -(x^2), not (-x)^2), and so the operand of sine
must be -x^2, not just -x. Although this is perfectly well defined,
it is far better to write (sin x)^2 rather than sin x^2, and sin(-x^2)
rather than sin -x^2. I consider sin x^2 to be sloppy because,
although it is clear to the computer, it leads the HUMANS to be
confused.
That is why I consider \sqrt\frac{a}{b} to be sloppy. I pointed out
that others will feel differently, but that's my opinion. If you can
answer the quiz above correctly (without running TeX first), I might
be persuaded to reconsider that.
Even if I didn't consider is sloppy, however, it is still not easy to
make MathJax do it the same way TeX does. That is because TeX's rules
are based on the difference between macros and primitives, and how
they differ in TeX's mouth and stomach. These concepts are not part
of MathJax, and so the rules don't transfer over to MathJax very
readily. To be able to handle this type of usage, MathJax's internals
would need to be redesigned. (To be fair, I could make MathJax accept
\sqrt\frac{a}{b} fairly readily, but it would also then accept things
like \sqrt\sqrt{x} and other constructs that are NOT legal in TeX.)
Davide
Paul Topping
that Knuth was not a computer language expert or simply chose his own ad
hoc strategy. As you note, treating macros and primitives differently is
a bit crazy. Programming languages often have sets of keywords where
members of each can appear only in certain places. I think it is the
fact that TeX's two sets of words seem to be from a single set based on
the rest of the syntax that throws things off.
I do come from a computer language background and I understand that the
only reasonable way to get MJ parsing to match TeX's is to pretty much
duplicate the appropriate parts of its machinery (omitting the ability
to modify character categories, for example). Perhaps you felt that
following a simpler syntax was an improvement. I can certainly see that.
Of course the downside is that there exists TeX users whose hands know
TeX's arcane syntax and directly channel Knuth on such things. And, of
course, users want to use expressions that have already passed a real
TeX parser and feed them to MJ. Some number of these will require TeX's
arcane rules to parse properly.
nageh
will expect things to work the way they do in TeX. Not necessarily
because they know exactly how TeX works internally but because they
got used to constructions they figured do work in TeX.
I will file a bug report as suggested. I point out that it may not be
necessary to change the internal MathJax logic because it might be
possible to special-case those few cases where a different parameter
prioritization is required (e.g., for \frac).
-nageh
Victor Ivrii
> Davide, I must confess that I failed your test. Still, other users
> will expect things to work the way they do in TeX. Not necessarily
> because they know exactly how TeX works internally but because they
> got used to constructions they figured do work in TeX.
Let consider documentclass memoir. It does not accept \bf, \it etc
requesting to use \textbf, \mathbf, .... When first I began to use
memoir, it annoyed me for a couple of days but then I began to use it
always, not necessarily in memoir.
There are plenty of TeX users and an absolute majority learned it
using few samples of unknown quality and advices of people who learned
TeX the same way. As a results a lot of mathematical papers around are
full of deprecated, sloppy, ugly, pervert constructions. I definitely
prefer more restrictive behaviour and I applaud attempts of Davide and
the team to promote more sane TeX.
There are tons of TeX features which are more relevant and which are
not supported and some of them will never be supported. F.e. \\[2pt]
in multiline constructions even with AMASMath loaded (I did not check
it all).
>
> I will file a bug report as suggested. I point out that it may not be
> necessary to change the internal MathJax logic because it might be
> possible to special-case those few cases where a different parameter
> prioritization is required (e.g., for \frac).
>
> -nageh
Victor
--
========================
Victor Ivrii, Professor, Department of Mathematics, University of Toronto
http://www.math.toronto.edu/ivrii
nageh
_independent_ of any documentclasses or other packages you are using!
In other words, it is standard TeX and thus should be supported. Yet
in other words, MathJax should not _redefine_ TeX.
Of course your opinion may (and does) vary.
-nageh
On Feb 25, 11:44 am, Victor Ivrii <viv...@gmail.com> wrote:
Davide P. Cervone
> _independent_ of any documentclasses or other packages you are using!
This is not entirely correct, as a package could redefine the standard
control sequences so that they work differently. For example, it
would be easy to redefine \sqrt so that \sqrt\frac{a}{b} worked the
same as \sqrt\sqrt{x} and the others.
Davide
Davide P. Cervone
> not supported and some of them will never be supported. F.e. \\[2pt]
> in multiline constructions even with AMASMath loaded (I did not check
> it all).
WYI, \\[2pt] is on the list of things to add, but not in v1.1. Once
that is out the door, I will be able to work again on some of those
smaller issues that need to be added.
Davide
Victor Ivrii
There is an extension to amsmath - mathtools which allows the more
fine tuning, in particular useful is \shortintertext{}, but also
\smashoperator{}. It would be nice to have it supported in 1.9 or 2.1
:-)
Davide, I know, you (all developers) hate this question, but I still
ask: when 1.1 is planned to be released? Yes, myself I use 1.1beta but
our Department (and all more conservative places) use 1.01a.
Furthermore, I tried few months ago to suggest arXiv to use MJ, and
now when it became more accepted I will try it again - but it would be
better to do it after 1.1 released.
Phillip Lord
It has to. TeX is complicated and it's only going to work identically,
if mathjax is actually tex, which it isn't. As Davide mentions from the
user perspective, it's perfectly possible for TeX packages to redefine
TeX anyway. And, even if mathjax attempted to implement tex exactly,
there would still be bugs.
The question is not whether there should be differences; the question is
how many users are going to be irritated by an individual difference,
which should give a reasonable idea of whether it needs to be fixed.
Both wikipedia and wordpress will have access to a significant body of
web-page embedded tex -- wikipedia because in their data and wordpress
because the standard implementation of their tex->image plugin
translates on wordpress.com. They would probably be willing to provide
access to it; so the question is even answerable.
Just a thought.
Phil
nageh
and something that works _differently_ than to be expected. Of course
MathJax cannot (and should not) replicate TeX in full.
Davide, I am fully aware that packages _may_ redefine parameter
precedences but I would hope that no _sane_ package would do so.
Anyway, it is not up to me to decide what should be done.
-nageh
Davide P. Cervone
>> Once that is
>> out the door, I will be able to work again on some of those smaller
>> issues
>> that need to be added.
>
> There is an extension to amsmath - mathtools which allows the more
> fine tuning, in particular useful is \shortintertext{}, but also
> \smashoperator{}. It would be nice to have it supported in 1.9 or 2.1
> :-)
It may be possible to do \smashoperator, but \shortintertext has the
same problem as \intertext, which is that there is no natural way to
handle it in MathML. Since the internal format for MathJax is MathML,
this is a requirement for anything that MathJax will produce. I
haven't been able to think of a way to accomplish it that would work
reliably.
> Davide, I know, you (all developers) hate this question, but I still
> ask: when 1.1 is planned to be released? Yes, myself I use 1.1beta but
> our Department (and all more conservative places) use 1.01a.
> Furthermore, I tried few months ago to suggest arXiv to use MJ, and
> now when it became more accepted I will try it again - but it would be
> better to do it after 1.1 released.
"Real soon, now" I think is the approved response to such
questions. :-)
I'm not actually in charge of the release schedule, but there are
several steps still to be completed.
Davide
Davide P. Cervone
place on Wikipedia, and believe me, there was some horrible stuff
there. I haven't looked at it recently, but as I recall, there
certainly were instances of things like \sqrt\frac{a}{b} and a few
other things that would cause MathJax some trouble. At some point, I
will work up an automated test procedure and run the database through
MathJax to get a better idea of where it fails.
Davide
Davide P. Cervone
> precedences but I would hope that no _sane_ package would do so.
Your comment suggests that such things are only done intentionally,
but I doubt that that is the case very often. The fact that \sqrt
\frac{a}{b} works was probably not intentional (though I certainly
don't know for sure). It is basically a lucky accident of the
definition of \frac (and the definition of \sqrt). It would be very
easy to break that lucky accident by redefining either one. For
example,
\let\oldsqrt=\sqrt
\def\sqrt#1{\oldsqrt{#1}}
would cause \sqrt\frac{a}{b} to fail. This is an easy thing to do
without realizing the consequence to the \sqrt\frac construction
(which is another reason that \sqrt{\frac{a}{b}} is a more effective
syntax).
My feeling is that the fact that the \sqrt\frac{a}{b} construction
works is a quirk, not an intentional design. Using it means you are
relying on a quirk, and (as always when you rely on quirks), you take
a risk in doing so, because that quirk may not be present in another
context where you might want to use that construct. When you switch
to that new context, you may have to change what you do. That's the
nature of quirky behavior.
As for wether it is insane to make a change that affects these quirks,
such changes are probably no more intentional than the original
behavior was, and I certainly would not expect a macro writer to try
to maintain what I consider an accidental interaction. It is the
insistence that $\sqrt\frac{a}{b}$ is "standard" when $\sqrt\sqrt{x}$
and $\sqrt\overline{x}$ and $\sqrt\ln{x}$ and $\sqrt\vec x$ and
virtually every other compound construction FAILS to work is what I
find questionable. That is not meant to be an insult, but merely to
point out that the inconsistent behavior is that \sqrt\frac{a}{b}
works in the first place, not the other way around. That people have
come to rely on what is clearly a mistake (or at best an accident) is
unfortunate, but I do not consider it insane to provide a package that
doesn't maintain that mistaken behavior.
Davide
Phillip Lord
It's just a thought. My general use of maths is fairly limited, and
mathjax more than fulfils my requirements. These days, I tend to write
for the web in the first place, so I'm just as likely to get annoyed
when tex doesn't work the way mathjax does as vice versa.
Phil
--
Phillip Lord, Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: philli...@newcastle.ac.uk
School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower, skype: russet_apples
Newcastle University, msn: m...@russet.org.uk
NE1 7RU twitter: phillord
Victor Ivrii
<philli...@newcastle.ac.uk> wrote:
>
>
> It's just a thought. My general use of maths is fairly limited, and
> mathjax more than fulfils my requirements. These days, I tend to write
> for the web in the first place, so I'm just as likely to get annoyed
> when tex doesn't work the way mathjax does as vice versa.
>
I am very annoyed dealing with TeX perverts when reviewing a paper -
sometimes pdf output is not enough - but even this abomination works
in MJ with AMSMath
$$
\newcommand\eeeekv[5]{\begin{eqnarray}\label{#1}#2 \\ #3
\nonumber\\#4\nonumber\\#5\nonumber\end{eqnarray}}
\eeeekv{gu.8}
{&&E_+v_+={1\over \sqrt{\alpha }}\sum_1^N v_+(j)e_j,}
{&&E_-v={1\over \sqrt{\alpha }}\sum_1^N v_j\delta _j,}
{&&E_{-+}=-{1\over \alpha }{\rm diag\,}(\sqrt{\lambda _j}),}
{&&\Vert E\Vert ,\Vert E_+\Vert ,\Vert E_-\Vert ,\Vert E_{-+}\Vert
\le {1\over
\sqrt{\alpha }}.}
$$
Robert Miner
From my point of view, the questions about fidelity of TeX support in
MathJax are at least as much empirical as ideological.
I see there are many long-time TeX users in this discussion, and so you
all know there are no answers to these question. We might as well
debate whether emacs or vi is the better text editor. It is well-known
that TeX syntax is obscure, fragile and susceptible to unindented
side-effects, which is why there have been many efforts to regularize it
over the years, and why many/most large STM publishers have moved away
from it as a production format. But it is also well-known that it is a
very widely-known and successful linear syntax for math in spite of
that. I think it is also clear that it isn't on the table for MathJax
to exactly replicate TeX, so it is a question of where to draw the line.
So what should the criteria be for making that decision? Here are a few
that are implicit in the current discussion:
1) experienced TeX users are going to expect certain things to work,
even if they
are a bit quirky
2) more regular, less quirky markup is easier to document, learn, and
robustly
manipulate programmatically
3) for converting large amounts of legacy data, greater fidelity to TeX
is
a big advantage
4) for large quantities of newly generated data, more regular markup
comes at
low incremental cost, and adds long-term values
In a perfect world, I'd like to look at present and likely future uses
of MathJax, get a sense of their relative size and importance, and how
bad the pain will be in the other cases. But of course, it isn't a
perfect world. In the past, I've been involved with several other TeX
converters, and in those cases ended up special casing \frac12 and
\sqrt\frac{1}{2} and similar common cases on account of the pleas of
users. On the other hand, in a math search project I worked on, the
virtual impossibility of robustly cleaning up really quirky markup
programmatically was the major limiting factor. Looking forward, it
seems like semantic uses of electronic data via smart agents is a really
huge potential payoff to walk away from, and so my instinct is to build
for the future and say we should just eat the cost of breaking bad
habits now.
Yet at the same time, I am keenly aware that if the bar to migrating to
MathJax is too high, either for existing content, or because of author
habits, it will limit adoption, and the current tower-of-babel of math
formats on the web will continue, and smart agents for semantic
applications to scientific knowledge will remain out of reach.
Ironically, precisely because of the difficulty of programmatically
adding in the missing {} to disambiguate expressions and so on, one
can't very well tell people to just fix up that collection of 500000
arXiv documents to put them online with MathJax...
At any rate, I appreciate the thoughtful discussion, and hearing all
your views and use cases, since that is what is needed to make a good
judgment about each specific case.
Thanks,
--Robert
> -----Original Message-----
> From: mathja...@googlegroups.com [mailto:mathjax-
> us...@googlegroups.com] On Behalf Of Phillip Lord
> Sent: Friday, February 25, 2011 9:28 AM
> To: mathja...@googlegroups.com
> Subject: Re: argument not enclosed in curly braces not accepted
>
>
>
Victor Ivrii
> Hi.
> Yet at the same time, I am keenly aware that if the bar to migrating to
> MathJax is too high, either for existing content, or because of author
> habits, it will limit adoption, and the current tower-of-babel of math
> formats on the web will continue, and smart agents for semantic
> applications to scientific knowledge will remain out of reach.
> Ironically, precisely because of the difficulty of programmatically
> adding in the missing {} to disambiguate expressions and so on, one
> can't very well tell people to just fix up that collection of 500000
> arXiv documents to put them online with MathJax...
I am not sure but some people seem to expect to be able to copy-paste
30pp math article to MJ and get an instant nice result. This is
definitely not the case due to pagination, sectioning, lists,
theorem-type environment, graphics etc etc
To make things more complicated often people paste not into html, but
f.e. editing mediawiki page. Sometimes where {multline} looked nice in
TeX output it is better in MJ if replaced by {align} or {gather}.
Leave alone that if some packages were used in TeX, one needs to
overcome the lack of such extension in MJ.
So, if I take a small paper (say, < 5 pp) and pate LaTeX source into
wiki I **expect** to perform certain work, far exceeding putting
braces in several pages where any sane author is expected to put them
anyway.
Davide P. Cervone
Paul Topping
drawn. My suggestion is that the line be drawn at not implementing in MJ
any TeX mechanism that changes how it parses things. I realize that this
is a bit vague but it is intended to be. Macros are a useful and fairly
easy to process abstraction mechanism and, therefore, are essential. But
changes to the how TeX treats characters seems like an abuse of the
language. It represents an attempt to make TeX do things it was not
really designed to do and should not be supported.
Paul
nageh
here) and supposed to work like that in MathJax or not:
\hat \mathbf u
gives an error in MathJax, but works in LaTeX and really should behave
like
\hat{\mathbf u}
Thanks,
-nageh
Davide P. Cervone
> here) and supposed to work like that in MathJax or not:
>
> \hat \mathbf u
>
> gives an error in MathJax,
For me, it gives an error in LaTeX as well. I get the error
! Argument of \select@group has an extra }.
<inserted text>
\par
l.20 $\hat \mathbf
u$
which is the type of thing you usually get when you don't use braces
around the arguments in a situation like this. This is in the amsart
document class. In the regular article class it does work as you
suggest, so it is not clear what the "right" interpretation of this
should be. MathJax doesn't have a documentclass, and so we don't know
which interpretation should be used.
The source of the error is the same as with \sqrt\frac{a}{b} as you
suggest. In MathJax, multi-token arguments need to be braced. I
don't want to reopen this argument again, but the reasoning is still
the same as before. If \hat \mathbf u works, do you think that
\mathbf \hat u should work, too? (It doesn't in either
documentclass.) Note also that there is an important difference
between \hat{\mathbf u} and \mathbf{\hat u}. The first puts a non-
bold hat on a bold u and the second puts a bold hat on a bold u. The
second is the preferred form, as the weight of the accent should match
that of the accented character, in general. So \hat \mathbf u should
be avoided for typographic reasons as well as.
If this use-case is important to you, however, you can do something
like we did in my suggestion for \sqrt, but this time you will have to
replace the Accent function for the TeX input jax. Copy the original
from unpacked/jax/input/TeX/jax.js and modify it to your liking. It
will be a little more complex this time since you will need to look
for more than one possible control sequence (\mathbf, \mathrm, etc),
but you should be able to use a regular expression pattern match for
that. I will leave the details to you, since my \sqrt example at
https://github.com/mathjax/MathJax/issues#issue/75
should be enough to get you started.
Davide
Victor Ivrii
> If this use-case is important to you, however, you can do something like we
> did in my suggestion for \sqrt, but this time you will have to replace the
> Accent function for the TeX input jax. Copy the original from
> unpacked/jax/input/TeX/jax.js and modify it to your liking. It will be a
> little more complex this time since you will need to look for more than one
> possible control sequence (\mathbf, \mathrm, etc), but you should be able to
> use a regular expression pattern match for that. I will leave the details
> to you, since my \sqrt example at
There are plenty things which work in LaTeX (and in MathJax) but are deprecated:
f.e. eqnarray. I have seen from my esteemed colleagues so ugly LaTeX
constructions that I wondered if my colleagues are humans or some kind
of aliens (MiB 3 :-) but these construction worked in LaTeX. I am not
sure that MJ should support any piece of alien code.
F.e. highly respected memoir class refuses to process \bf (and its
ilk) and I think that this is correct. There are things which seem to
be more pressing like automatic numbering (I know it is coming),
\intertext (I know it is highly problematic) and some packages. Not me
but some people would like to be able to draw commutative diagrams.
Davide P. Cervone
> be more pressing like automatic numbering (I know it is coming),
> \intertext (I know it is highly problematic) and some packages. Not me
> but some people would like to be able to draw commutative diagrams.
I agree. These are all things that need to be worked on. I'm
particularly anxious to get the automatic numbering in place. I'm
currently working on some performance issues, however, before more
feature additions.
Davide
nageh
others where less careless about omitting braces so I don't run into
these issues.
I'll probably adapt your example code.
Thanks again,
-nageh