AsciiMath: An easy-to-write markup language for mathematics
asciimath.org
asciimath.org
AsciiMath – An easy-to-write markup language for mathematics - https://news.ycombinator.com/item?id=13962242 - March 2017 (111 comments)
sum from {i=1} to n {i sup 3} = ({n(n+1)} over {2}) sup 2Someone’s gotta try to push the status quo forward on Unicode input.
For instance, while writing, the user inputs \alpha and the editor automatically converts it into the greek symbol right there in the source file. Later, when compiling latex transparently recognizes the greek symbol for what it is.
Sometimes I fire up a Julia repl purely as a unicode-getter.
sum_(i=1)^n i^3=((n(n+1))/2)^2
looks to me no less complicated than
\sum_{i=1}^n i^3=((n(n+1))/2)^2
so if the goal is it quickly communicate mathematics in plain text (without rendering), I see no difference. If the advantage is that the outer parentheses are automatically resized, why not write a renderer that uses Latex and puts \left, \right everywhere? Better yet, why not go straight to TeXmacs?
I'd love to see an example of a mathematical expression where Ascii math is visibly simpler than Latex and is not just about parenthesis resizing.
((a,b),(c,d)) |-> ul x < 10 != y ~~ (dz)/(dt) !in RR -> oo
\begin{pmatrix} a & b \\ c & d \end{pmatrix} \mapsto \underline x \lt 10 \ne y \approx \frac{dz}{dt} \notin \mathbb{R} \to \infty
Not at all a fan of using unescaped character sequences to represent non-latin characters. Ultimately, this leads to situations where you have to resort to some hack to write something that coincides with one of these special names.
Not to mention, this restricts extending the language for special use cases. Suddenly, you discover that you have to throw away the entire thing and resort to a math-typographically-complete language like Latex to write what you want to write.
Consider the example the page loads with "sum_(i=1)^n i^3=((n(n+1))/2)^2". Some of those parens are dropped entirely. Some are changed into taller versions. The + is not the same as the \plus sign that is rendered.
So, yes, it is a restriction that comes with some tradeoffs. My gut is that this is probably fine for the vast majority of use cases, though. Such that it was probably the right call.
s q r t
"sqrt"For example,
∑(i=1)^n instead of
sum_(i=1)^n
√x instead of
sqrt x
These keys aren't on my keyboard.
If they're on your keyboard, just reprogram them to emit `sum` and `sqrt` respectively.
Unicode is for viewing; keyboard locales are for inputting. We're never going to have 2^32 keys on our keyboards.
Using special chars even more.
Compose key is memetic and easy to use on all operating systems.
So? That's exactly what ∑√ allows you to do: view these nicer chars instead of the verbose/ugly names
> We're never going to have 2^32 keys on our keyboards.
And how is this relevant? You don't need 2^32, a much smaller number would suffice. Just read the posted link and count the number of rows - that's closer to your upper limit
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.
I use MathJax but would love to have a portable version of this.