Re: A proposal for a computer readable mathematical object notation

Do those "Most math programs" actually output this restricted, "properly"
structured MathML? To me, the value in something like MASTON is not what it
*adds* over MathML, it's what it *removes*. Volker's Speech Rule Engine is
a whole project unto itself at least in part because inferring structure
from MathML that ChromeVox encounters "in the wild" is so hard, no? That's
also why Content MathML and OpenMath exist, because people have seen the
need for this information to be part of the data structure and not have to
be inferred, before. (I would be curious to hear if Arno considered those?)

(Disclaimer: I specced out and built a toy parser for a JSON format for
display math, analogous to TeX and Presentation MathML but in contrast to
MASTON and Content MathML and OpenMath, that I called MathSON
<https://gist.github.com/laughinghan/4350e4438e6cfc951826>. I haven't
decided if it's any good.)

Han

On Thu, Mar 22, 2018 at 11:26 AM, Neil Soiffer <soiffer@alum.mit.edu> wrote:

> Previous email escaped too early...
>
> On Thu, Mar 22, 2018 at 11:07 AM, Neil Soiffer <soiffer@alum.mit.edu>
> wrote:
> Arno,
>
> I think the situation you describe about interchange is not anywhere near
> as bad as you think. Most math programs will except TeX or MathML as input
> and can do computation with them (at least Mathematica and Maple do so with
> MathML, and I think also TeX). Part of the reason those programs can do so
> is because they already have a linear syntax and so inferring a bit of
> additional information is not that bad.
>
> As for your proposal, I don't see what it adds that "properly" structured
> MathML doesn't already provide. My properly structured MathML, I mean
> MathML where the mrows reflect the abstract syntax of the mathematical
> expression. E.g, for a binary infix operator, the first element in the mrow
> will be an operand, the second the infix operator, and the third an
> operand. If the second operator is a relational operator such as '=', then
> the lhs is the first element and the rhs is the third element. The elements
> might be leaf nodes such as mi's or complicated expressions inside mrows.
> MathPlayer does this to infer semantics as does (I think) Volker's Speech
> Rule Engine.
>
> As an example,  e^{\imaginaryI \pi }+1=0
> <mrow>
>    <mrow>
>       <msup>
>          <mi>&#x2147;</mi>
>          <mrow>
>            <mi>&#x2148;</mi>
>            <mo>&#x2062;</mo>
>            <mi>&#x3c0;</mi>
>          </mrow>
>       </msup>
>       <mo>+</mo>
>       <mn>1</mn>
>    </mrow>
>    <mo>=</mo>
>    <mn>0</mn>
> </mrow>
>
> or in json format:
>
> {  "mrow": {    "msup": {      "mi": "ⅇ",      "mrow": {"mi": ["ⅈ","π"],"mo": "⁢"}    },    "mo": "+",    "mn": "1"  },  "mo": "=",  "mn": "0"}
>
>
> Note: although many operators such as '=' are formally binary infix
> operators, in practice, they are better treated as n-ary operators because
> they often are used as "a = b = c" or even "a = b <= c = d" and both layout
> and computation are often easier when all are at the same level.
>
> I believe several people have tried at various times to formulate a
> "canonical MathML" format that includes properly structured mrows, one of
> the canonical Unicode forms, and fixing up pseudo scripts
> <https://www.w3.org/TR/MathML3/chapter7.html#chars.pseudo-scripts> among
> some other things. Note that proper mrow nesting depends upon guessing
> between function call and multiplication if the author didn't indicate
> which to use (e.g, in MathML, one should use the invisible operators), so
> the parsing can be complicated. Of course, parsing alone doesn't provide
> semantics. I believe that Volker adds some attribute that is equivalent to
> adding something like a "mathrole" to various elements to specify semantics
> -- some "obvious", some derived from other context, etc.
>
> I think it would be helpful to develop a tool that anyone can incorporate
> to produce canonical MathML.
>
>     Neil
>
>>
>>
>> On Monday, March 19, 2018, Arno Gourdol <arno.gourdol@gmail.com> wrote:
>>
>>> As we’ve previously discussed, a notation to exchange mathematical
>>> expressions between computer programs could facilitate the assembly of
>>> software components.
>>>
>>> Consider for example the following category of components:
>>> - an equation editor
>>> - a numerical computation package
>>> - a symbolic algebra package
>>> - a graphing package
>>>
>>> While formats exist to represent what should be displayed to the user in
>>> the end (LaTeX, MathML, CSS+HTML), the situation is less encouraging when
>>> it comes to representing semantically a mathematical notation so that it
>>> can be acted upon by computer programs. As a result it is difficult to
>>> impossible to connect software components together.
>>>
>>> I’m proposing MASTON (Math Abstract Syntax Tree Object Notation), a
>>> lightweight, computer readable, notation for math based on JSON. I’ve put
>>> together a first draft https://github.com/arnog/mathl
>>> ive/blob/master/docs/MASTON.md and I am seeking feedback. Feel free to
>>> discuss on this mailing list or on github.
>>>
>>> Here’s Euler’s identity:
>>>
>>>         e^{\imaginaryI \pi }+1=0
>>>
>>>         {"lhs":{"lhs":{"sym":"e","sup":{"lhs":"ⅈ","op":"*","rhs":"π"
>>> }},"op":"+","rhs":1},"op":"=","rhs":0}
>>>
>>> Here’s a formula to convert degrees Fahrenheit to Celsius:
>>>
>>>         \frac {5}{9}(T_F−32)=T_C
>>>
>>>         {"lhs":{"lhs":{"num":"5/9"},"op":"*","rhs":{"lhs":{"sym":"T"
>>> ,"sub":"F"},"op":"-","rhs":32}},"op":"=","rhs":{"sym":"T","sub":"C"}}
>>>
>>>
>>> To test out the idea, I’ve also implemented MASTON support in MathLive
>>> and hooked it up to math.js to perform simple numeric calculations. On
>>> mathlive.io, click the </> icon to get a live output of what you type
>>> in MASTON, LaTeX and MathML. It’s a good way to get a sense of how it works.
>>>
>>>
>>> Best,
>>> Arno.
>>>
>>>
>>>
>