J

#### Juan R.

[http://canonicalscience.blogspot.com/2006/02/choosing-notationsyntax-for-canonmath.html]

was discussed with several specialists, including father of XML-MAIDEN

project (which provided many interesting ideas over original desing).

The initial CanonMath program (was abandoned) was presented at the w3c

mailing list for mathematics. There was little discussion but

subsequent discussion on others related MathML topics (formal structure

of Content MathML markup, script models, special entities, Unicode

composed diacritics vs <mover>, et cetera) benefited the development of

this new program.

Now the new CanonML approach is splinted into three modules:

i)

CanonText. This mainly a canonical expressions reformulation of the

initial Canontext module was based in XML in the old approach but now

is based in canonical expressions (modification of SEXPR).

ii)

CanonCode. This is a transformation/scripting/programming module. It

will be presented in next postings.

iii)

CanonFormal. It is the substitute of the old CanonMath, Canongraph, and

scientific modules. This is also based in canonical expressions now.

The change of name is justified because the language is used for

encoding of formal systems: either mathematical or scientific-technical

ones. Main features will be discussed here.

This new program substitutes to the old one. Ideas presented at

[http://canonicalscience.blogspot.com/2006/02/choosing-notationsyntax-for-canonmath.html]

are superseded by new ones. For example the initially chosen <over/>

tag is not already used for overscripts now and, therefore, we can

recover the TeX \over tag for fractions.

Formal structure]

The basic unit structure of a formal fragment is

[preargument1 ... \command postargument1 ...]

This is an infix notation and contrary to mainstream wisdom this is the

most general notation in formal systems. For example imagine that there

is not prearguments -i.e. preargument set is empty- then

[\command postargument1 ...]

That is, one recovers prefix notation as a special case. An example is

[\cos x]

Now imagine that there are not post arguments, then one obtains postfix

notation

[preargument1 ... \command]

A known case in mathematics is the factorial of a number

[23 \!]

The infix notation is preferred because easiness on writing by humans

and because contains others notations as special cases.

Both the infix notation and the formal canonical expressions design

unify the syntax doing parsing more easy for computers and the learning

more simple to users. The erratic TeX-like syntax (so critiqued in the

past by users) is avoided, but structure of mathematical markup is more

solid than that of ISO 12083 or MathML.

For instance, TeX commands

\stackrel{~}{f}

M_b

\sum_0^n

can be compared with their CanonFormal correspondences

[f \^^ ~]

[M \_ b]

[\sum \__ 0 \^^ n]

Note the erratic ordering of factors in TeX. For instance, the ordering

in the \stackrel command is overscript-base, but base-overscript in the

case of \sum. Note also that the TeX command "_" introduces subindices

when acting in M but introduces an underscript when applied to \sum. If

you want a subindex then you may consult your TeX manual (a TeX gurü

will work too ;-) for learning the way. In CanonFormal \_ always

introduces subindices whereas \__ introduces underscripts.

Note also that base is perfectly defined in CanonFormal. Problems on

parsing base of scripts and lack of any structural model for tensors or

prescripts are two sound weaknesses of TeX and similar models (e.g.

also of ASCIIMath). MathML or ISO 12083 improve this via specific

markup structures fixing bases. However, both approaches present

serious difficulties. MathML introduce bases as child of scripts

structures and this generate difficulties for extensibility of content

model, complicate the DTD a lot of at that point. Moreover, the MathML

script model returns CSS incompatibilities forcing an incorrect

implementation in browsers rendering engine.

All this is solved in CanonFormal; in a future posting we will see

detailed comparative review of script models in MathML, ASCIIMath,

LaTeX, amstex, ISO 12083 and CanonFormal, including illustrative

samples of code.

Computational advantages of postfix]

Due to his formal structure CanonFormal structures can be transformed

to either prefix or postfix (RPN) notation. In fact, there exist

standard algorithms for transforming infix notation to RPN: e.g. the

so-called shunting yard algorithm. In a future posting we will see how

an algorithm could be directly implemented in CanonCode: a

scripting-programming-transformation language based in own CanonML.

RPN has the computational advantage of being extremely easy to

computational analisis, increasing computer efficiency and speed. It is

also possible a better memory management.

For example the CanonFormal representation for (3 * 9) + 2 can be

easily transformed to

[[3 9 \*] 2 \+]

or even to

3 9 \* 2 \+.

This may be useful in computational science. E.g. the authors of

Biosystems 2003; 72(1-2); 159-76 presented a novel algorithm with RPN

design for reducing the computational cost.

Usage of invisible operators and others]

Invisible operators and special commands are useful for encoding

content, for computation and also for improving accessibility of

datuments.

For example, what do I mean by h(x+y)? The function h of (x+y) or maybe

the product of variables h and (x+y)?

TeX, IteX, ASCIIMath, or ISO 12083, between others, cannot disambiguate

the expression. In CanonFormal we can write

[h \function-of [x \+ y]]

or

[h \* [x \+ y]].

A search engine can discriminate between both expressions; aural

renderings for people with disabilities are those we wait, etc.

In theory, presentation MathML 2.0 can also differentiate both

expressions via application of specific entities ⁡ and

⁢. For instance, latter CanonFormal code may be

expressed in MathML 2.0 like

<mrow>

<mi>h</mi>

<mo>⁢</mo>

<mfenced>

<mi>x</mi>

<mo>+</mo>

<mi>y</mi>

</mfenced>

</mrow>

But I remarked the "in theory" because in practice MathML is not

authored by hand due to its unusual verbosity and many popular tools

(including tools generating the MathML code used in some academic

journals as Living Reviews in Relativity (Hermes) and scientific blogs

such as Musings from J. Distler) are *not* using invisible operators.

Semantic correctness and accessibility of the real MathML code is being

served in the Internet is very limited.

Similar thoughts are applied to dx (encoded as [d \* x]) versus dx

(encoded as [\differential x]).

The situation in MathML documents served on the Internet is still poor.

The differential is not usually encoded via special entity and,

therefore, confounded with others d; a very basic concept such as the

"square of differential of s" is being incorrectly encoded as "two

times s times ds". This incorrect encoding is being served to the

Internet in several articles of HERMES - Living Reviews on relativity

journal and also in Distler's blog Musings on string theory and

related stuff. See

[http://canonicalscience.blogspot.com/2006/04/scientific-language-canonml-is.html]

for further details and links to Distler's blog articles. In the next

HERMES generated document

[http://hermes.aei.mpg.de/2005/2/article.xhtml]

you can find the MathML 2.0 code

<mi>d</mi>

<msup>

<mrow>

<mi>s</mi>

</mrow>

<mrow>

<mn>2</mn>

</mrow>

</msup>

just after the section 2.1. It is obvious that accessibility,

structure, "semantics", encoding, and rendering of this code are all

wrong. Moreover, the HERMES generated code contains redundant <mrow>

tags. Mozilla developers carefully recommend avoiding redundant <mrow>

by technical motives: performance and memory consumption.

[http://www.mozilla.org/projects/mathml/authoring.html]

In a future posting we will see that there exist more problems with

redundant mrows than those are being listed in the mozilla page.

Even if you fix by hand the above weird MathML code, correct it, and

introduce the entity ⅆ, the code will suffer from

additional difficulties. The MathML entity for differentials will be

visually rendered as a double-struck d, instead of the more usual roman

d.

David Carlisle in

[http://lists.w3.org/Archives/Public/www-math/2006Apr/0051.html]

and others MathML WG folks replied that for visual rendering a roman d

the best way in MathML may be to use a simple d in the input file, for

example <mo>d</mo>.

But the own MathML 2.0 specification does not recommend that way!

Using something as <mo>d</mo> you obtain a not very convincing visual

rendering, incorrect aural rendering for people with disabilities, and

you confound search engines.

The second option is to use MathML recommended code

<mo>&Differential;</mo>, then search engines can recognize

differential, the aural rendering is correct, but one obtains a default

non-standard visual rendering cannot be modified as some folks worried

at the list.

All those problems are absent in CanonFormal. Search engines can

distinguish then a simple d from the \differential command. Aural

renderings read "differential of" for blinded users, and the visual

rendering of the command is set to a roman d by default but can be

changed by the user via "stylesheets" when desired.

Source:

http://canonicalscience.blogspot.com/2006/05/canonml-as-authoring-system-for.html