Re: How do I encode negative numbers in content MathML?

Charles Lyons wrote:
>
> When I was working on a content MathML processor, it made sense to
> require that only the <minus /> be permitted, and that all numbers be
> positive. This meant that such things as -(-1) could easily be
> simplified by recognising the presence of two <minus /> elements
> (which could then simply be removed from the DOM and disregarded).
> Of course, an input parser can easily work with <cn>-1</cn> be
> recognising the - sign and turning it into <minus /> then
> <cn>1</cn> internally.

Yes, there are several reasons which I prefer usage of minus on a positive
number: Unification of encoding (-b) vs (-1), the fact that -(-1) cannot
be encoded as <cn>- -1</cn> not as <cn>-<cn>-1</cn></cn> and then I prefer
a nested apply.

I also am inspired in certain FRANZLISP formal structures where (-1 79) is
different from (- 1 79). However, note there is not ambiguity on MathML
due to tokenization.

> We had the same problem with complex numbers using the <cn> and <sep />
> elements, and eventually decided just to use integers/decimals in <cn>
> and use <imaginaryi /> and <plus /> where necessary. This was more
> flexible in the long run and allowed for pure imaginary numbers with no
> parsing problems... I dislike using <sep /> anyway as its semantics
> depend on the type of number being parsed and aren't 'obvious' from
> the outset.

Completely agree, I dislike the <sep/> content model. What is more, I am
not using a real number model like <cn>1.2345</cn> because formal reasons
on CanonML and because that kind of content MathML encoding is mixing
presentation and content. It is assuming that presentation "." *is* the
decimal sign.

A future IUPAC report prepared by the Physical Chemistry Division (I
accessed to a draft version of recommendation) already recognizes usage of
comma and highlights that ISO 31-0 (1992) recommends comma. In Spain, one
writes 3,1416 instead of 3.1416.


Michael Kohlhase wrote:
>
> Interesting that you should ask just now, I have been stumbling over the
> same thing a couple of days ago. The difference becomes interesting when
> you try to do presentation with bracket elision.
>
> The general idea is that when we have
>
> <apply>
>   <or>
>    <apply><and><ci>a</ci><ci>b</ci></apply>
>    <apply><and><ci>c</ci><ci>d</ci></apply>
> </apply>
>
> which should give a /\ b \/ c /\ d since /\ binds more strongly than \/.

In a markup language based in canonical expressions you would use brackets
for the infix version

[[a /\ b] \/ [c /\ d]]

whereas you could translate it to a full RPN version in computational
algorithm for improving efficiency

a b /\ c d /\ \/


Richard Kaye wrote:
>
> This issue is perhaps peripheral to the original question,
> but it is interesting enough.  I came across an identical
> problem this morning, when I was writing a quick and dirty
> stylesheet to convert XHTML+p-MathML into
> plain old HTML

I suppose that you refer to HTML 4.x because HTML 5 is more modern than
XHTML 1.x.

> that could just about be readable by people
> without the right browser.  (Basically, the only thing
> helpful in HTML is <sub> and <sup>.)  I had to
> translate mfrac's as ((numerator)/(denominator))
> and have ended up with many places where there
> are too many brackets.

HTML 4.x is more useful than that!

Code as next

<span class="f">
  <span class="n">numerator</span>
  <span class="d">numerator </span>
</span>

can be used in a HTML document and fractions rendered via CSS in browsers
without MathML support.

In fact, main difficulty with George (XML-MAIDEN) is not limitation of XML
or HTML but lack of solid implementations of CSS 2.1 in today browsers.
For example, fractions are broken if you try to see articles in XML-MAIDEN
site with Firefox 1.0, because a bug with inline blocks. The bug is
scheduled to be fixed in a next version of Firefox and you will see it
correctly. See the sample in pdf for an illustration of the power of
George technique. He can see more math with Opera (or any other compliant
CSS 2.1 rendering engine) i can see with a Firefox with specific native
support for p-MathML.

However, George is working in a new CSS approach and developing a CSS
cross browser stylesheet that would work very well (not perfect) for today
Safari, MSIE, Opera, Firefox, and others.

See, for example, some days ago update on experimental CSS technique for
Firefox using special mozilla extensions:

[http://geocities.com/chavchan/exp/moz-frac.xml]

Of course, once browser developers correct bugs with CSS 2.1, all browsers
will be able to render complex mathematical formulae without specific
p-MathML support, as Opera is already able to do today. Situation would be
better with future Math module in CSS 3.

Any information on future CSS math module MathML folks? What properties
will be introduced?


Juan R.

Center for CANONICAL |SCIENCE)

Received on Friday, 19 May 2006 14:01:08 UTC