# Re: Content MathML editing language: Binary => n-ary syntax

Date: Mon, 20 Nov 2006 01:39:25 -0800 (PST)
Message-ID: <3151.217.124.69.196.1164015565.squirrel@webmail.canonicalscience.com>
To: <www-math@w3.org>
```

> Comparing a+b+c with (a+b)+c is more interesting, because the order of
> operations in the same. This is actually a slight discrepancy between
> content MathML (where plus is an n-ary operator) and and the standard
> approach for studying groups in mathematics (because the usual
> definition of a group makes the operator a binary operator).

In rigor c-MathML arises from LISP (plus a b c) and the plus is a
function, not a binary operator. Therein the <apply>: "Apply the function
plus to the arguments a, b, and c".

People becoming from C languages often do not notice that the LISP form (+
a b) means +(a, b) in C-like notation because in LISP (contrary to C)
there is no restriction in naming functions and + is a valid name for a
function.

Note that in rigor the + in (a + b + c) are not binary because the
structure is not binary. This is a notation for recursive binary!

> I am not
> aware of any document which defines how the n-ary operators on a
> variable in content MathML map onto the binary operator plus.

Basically you follow the same steps that when defining the notation (a + b
+ c) in mathematics.

In CanonML we mimic math: E.g. [a + b + c] => [a + [b + c]]

> In this case, the value of the expression is not changed between a+b+c
> and (a+b)+c, and therefore, the meaning shouldn't be changed (the only

If and only if + is associative, wich may the case in CellML for all
practical cases.

However, note that is not the case in more general languages. Example, in
canonical science [A + B + C] is not the same than [[A + B] + C].

The first maps to one Keizer law, whereas later maps to a sequence of two.

In chemical calculus (a variation of Boole algebra: X + Y = XY), in
general (A + B) + C is different than A + (B + C), therein than A + B + C
has not the same meaning than usual algebra in math.
```
Received on Monday, 20 November 2006 09:39:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:42:12 UTC