I guess it’s just more “natural” and less latex like.
$$\sum_{i=0}^n i^2 = \frac{(n)}{2}$$
Vs
sum_(i=o)^n i^2=((n)/2)
1. https://docs.asciidoctor.org/asciidoctor/latest/stem/asciima...
So technically a web could indeed be a different place: a network of XML documents where all the original notations are kept as they are and merely marked with tags that formally specify: this is AsciiMath, this is C, this is SQL, and so on.
LaTeX has been the industry standard for the mathematical world for decades and as a result it has had the most work adding new notation or making nicer formatting.
For example, I needed to do a proof tree recently. Typically I would use bussproofs in LaTeX but I was using Typst, and while there is a package for handling proof trees in Typst [1], I think they're not very pretty, and as a result I ended up porting the document over to Pandoc markdown and doing the rest of my work there (which is annoying because Typst renders around ~1000x faster and has better tooling).
I suppose I should change the title to say “Why an AsciiMath Dialog” and then add another subsection “Why not AsciiMath”.
The short answer is that AsciiMath is an excellent language IMO but a rather lacking implementation. Shortcomings of this particular dialog are raised in a different thread here, but for me personally the biggest issue was in the output format. AsciiMath is pretty tightly integrated into each implementation (like MathJax) instead of just outputting standard MathML. I also altered the dialog a bit, e.g. the matrix notation is a bit different in mathup, and I also add the possibility to use whitespace to group sub-expressions (similar to typist).
There are also small differences in the language, main one being the use of whitespace to group expressions in mathup (similar [but not identical] to typist).
It was the key for me being able to write maths in a classroom/lecture theatre at the same speed (or faster) than those doing it by hand.
The "AsciiMath" name reveals volumes, because prior to rendering, LaTeX code is already ASCII characters meant to represent math symbols. We just didn't call it that.
Oh well, a tempest in a teapot, soon to be forgotten. We can already tell a chatbot, "Show me the tensor equations of General Relativity, and render the result in LaTeX."
I close with the obligatory XKCD reference: https://xkcd.com/927/
It's, in project's words, simple calculator-style syntax (can also call it simplified LaTeX subset or that ad hoc math syntax used in emails but standardized) made to easily embed math on web pages by converting to MathML, with its existence predating MathJax by few years (and even MathJax's predecessor, jsMath). It was never meant to be LaTeX competitor.
With last point, have noticed people most often use this xkcd strip opposite to what it means. It's about when, for a particular use case, one standard/tech/whatever tries to replace all others rather when one standard/tech/whatever attempts to fulfill a distinct use case.
> LaTeX code is already ASCII characters meant to represent math symbols
Not really, it's long \escaped \English \words that are made of ascii symbols, a difference clear if you just look at the comparison table
$3\times4$
vs 3 xx 4
sum_(i=1)^n
How about using some symmetry instead, e.g.
sum(i=1)(n) "Means: sum from i=1 to n"The caret is used to indicate the upper limit for the same reason some programming languages use it as the exponentiation operator (other programming languages may use something else, like **, neither is normally how exponentiation is “normally”, outside of programming and its historic limitation to ASCII characters, indicated), because its upward-pointing character is a considered a way of suggesting that the following number should be thought of as presented raised from the normal baseline, which is (in somewhat different ways) true of both exponents and upper limits in summation (this is the mirroelr image of why _ is used for the lower limit.)
o ox x = xo
a ax x = xa
ooxx=xo
aaxx=xa
ac+sinx+xsqrtx+sinsqrtx+sinsqrt(x)
o ⊗ x = x o
a a x x = x a
∞ × = x o
a a × = x a
a c + sin x + x √x + sin √x + sin √x
[0]: https://tug.org/TUGboat/tb36-2/tb113hagen.pdf#page=3
[1]: https://github.com/contextgarden/context/blob/e9bd55ec/tex/c...
Significant whitespace is totally fine, but whitespace that is sometimes significant and sometimes not isn't. In the examples above, "sinsqrtx" produces the same output as "sin sqrt x", but "ooxx", "o ox x", and "o o x x" all produce completely different output.
2x+3=(2x)+3 != 2(x+3)
Parentheses are also "sometimes significant and sometimes not".
asciimath’s choice here is to make whitespace (sometimes) optional between two subsequent alphanumeric tokens, and it is a rather odd choice. I‘m not sure which other language (markup or otherwise) does it this way.
Ouch. I wrote a couple of parsers when I was young and foolish without trying to specify the grammar, and it’s a good thing they didn’t get popular, because every bugfix changed the syntax and broke texts that had been working before.
alphanumeric tokens MUST be separated from each other with a symbol or whitespace.
ooxx => ooxx
oo xx => ∞×
sqrtx => sqrtx
sqrt x => √x
sqrt(x) => √x
Now that I'm older and wiser I think the whole thing is a waste of time and a perfect example of cargo culting. The current maths notation was largely invented by Euler so he could write to his contemporaries with parchment and quill, e.g. https://www.themorgan.org/blog/all-math-nerds-out-there
That we are still using his notation three centuries later on computers is both astonishing and saddening.
It's much better to use a sane and consistent notation that can be entered as ascii in the first place (or Unicode if you hate long names), viz. s-expressions.
| TeX | S-Expression |
|--------------+-------------------------------|
| 1 + 2 | (+ 1 2) |
| 1 - 2 | (- 1 2) |
| 1 \times 2 | (* 1 2) |
| frac{1}{2} | (/ 1 2) |
| a_i | (map a (range 0 n)) |
| \sum_i a_i | (apply + (map a (range 0 n))) |
| \int x^2, dx | (integrate '(expt x 2) 'x) |
Even though we might use a digital device, its output is still visual, so it is unclear why Euler's notation (which is a subset of mathematical notation) is obsolete. Latex is a tool for creating documents, not programs or proofs. So it's natural that it tries to make the conversion between what we want to see and what we want to write as seamless as possible.
In both cases a superior system was held back by people too used to an inferior one to understand why they need something better.
That said, your system kinda exists already (and has been for decades). Mathematica can be written fully in M-Expressions (given any expression can recover the M-Exp with `FullForm[HoldForm[...]]`) and can convert to TeX (given any expression with `TeXForm[HoldForm[...]]`) for each if you want.
| TeX | M-Expression |
|--------------+-----------------------------------|
| 1 + 2 | Plus[1, 2] |
| 1 - 2 | Plus[-1, 2] |
| 1 \times 2 | Times[1, 2] |
| frac{1}{2} | Times[2, Power[2, -1]] |
| a_i | Map[a, Range[0, n]] | (* or better: a[i] *)
| \sum_i a_i | Apply[Plus, Map[a, Range[0, n]]] | (* or better: Sum[a[i], i] *)
| \int x^2, dx | Integrate[Power[x, 2], x]]] |
There's also Emmy which is a vastly expanded port of scmutils (from SICM) embedded in Clojure but haven't used it much. Being embedded in Clojure, uses sexps and, when used in Clerk environment, can render to TeX.
As for m-expressions they also came from lisp, but were abandoned because s-expressions had so much more expressional power, since they were composable as expressions and as code.
Who are the "remaining browsers" here? caniuse suggests support across all the usual suspects (albeit I think some implementations leave a lot to be desired on the formatting end of things)
Wayback Machine investigation: from the first capture in https://web.archive.org/web/20141227061758/http://asciimath.... until https://web.archive.org/web/20171213211317/http://asciimath...., that line read:
> As HTML5 including MathML has currently become an official recommendation, the remaining browsers are likely to follow with first implementations soon!
Then, finally accepting that Google did not intend to support MathML, by https://web.archive.org/web/20171113100326/http://asciimath...., they changed it to what you read today:
> While HTML5 now includes MathML as an official recommendation, the remaining browsers do not appear to be implementing it. For widest browser compatibility, the use of MathJax is recommended.
Since then, Edge has abandoned its own engine in favour of Chromium, and Igalia has driven MathML with the end result of MathML Core (a reduced and better-specified subset of MathML) and an implementation in Chromium.
In fact, I found that writing as much math as possible in Unicode makes for the best HTML reading experience: it's fast, simple, and looks more natural (avoids font inconsistency and line-height jagginess, among other things). https://gwern.net/design-graveyard#mathjax
And if you find writing Unicode yourself a pain, you can just ask a LLM to translate from LaTeX to Unicode! https://github.com/gwern/gwern.net/blob/master/build/latex2u...
For reference, here is my personal (still evolving) .XCompose https://github.com/chtenb/dotfiles/blob/master/.XCompose
AAccAltccBinbbbR,cc|A|ltoo
[0]: https://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.1....
JoelMcCracken•2mo ago
Rendello•2mo ago
1. https://docs.asciidoctor.org/asciidoctor/latest/stem/asciima...