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

This letter brings up an interesting point.

Speaking (as an applied math person) on pedagogical
points, I'd like to share something I found, a common
"programmer's view" (in this case the language
was C and C++) on some similar items: the rules of
the order of precedence when processing a complex statement.
Having cut my teet on Copi, I found the following quote a disturbing
description of what people perceive as important. I could be
wrong but perhaps the perception of  /\ and \/ falls in the
same category?

>From "Ace the Technical Interview", Eds. Rosthein and Rosthein,
p. 269 (popular press is always a good way to judge how a lot
of people see things)...

Q. Should a programmer rely on the rules of the order of precedence
when processing a complex statement?

A. No, parentheses should be used to clarify the order of precedence
in a complex expression. Programmers cannot be expected to
remember the orders of precedence.

The example then given was

int i = x + b * c / n + a; which was then written with parentheses to
illustrate the point.

This disturbed me greatly when I read it. In other words, I think
the problem, if there is one, extends far beyond /\ and \/. I cannot
imagine someone then trying to text it without your brackets or
some specific identifiers for clarity. In C++ for example, I believe
the order of preference specifies that the increment operator is
higher in precedence than the relational operators. If you don't code
it right, you have no assurance that the correct operand would
be evaluated first. When documenting code then it would become
critically important how you represented your statements so people
would understand both the mathematics and what the code was
trying to represent.

>From this I infer that writing software (depending on the language)
might have its own interpretations and that software writers will have
differing
views on importance of logical symbols and the theory of arithmetic,
depending on what they know. This would then naturally extend to
how that might be annotated in text. Maybe too many brackets is
the only thing that makes sense.

Leane

Leane Roffey Line, Ph.D.
Research Engineer
www.bioelektronika.com
Neuro Magnetic Systems
San Antonio, TX 78209






----- Original Message -----
From: "Richard Kaye" <R.W.Kaye@bham.ac.uk>
To: <www-math@w3.org>
Sent: Friday, May 19, 2006 5:46 AM
Subject: Re: How do I encode negative numbers in content MathML?



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 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.

By the way, it just happens that I am currently writing
a text on logic. In this, the duality between /\ and \/ is
so important a pedagogical point that I would never
break the duality by saying one binds more strongly
than the other.  (In fact that's my position at all times
when and and or are notated this way - not just in this
particular text.  When they are notated && and || it's a
different matter.)  So I would always have brackets in this
example.  I guess you must be writing some software that
has a default behaviour to omit brackets here. I trust that
if I were using it there would be a way I could over-rule this
default.  You could go even further and reconsider whether
you have the right default.  But I honestly have no idea
how many other people have a strong view on this point.

Best wishes

Richard




On Thursday 18 May 2006 18:44, 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 such situations you want to have -(a+b), i.e. the unary minus
> operator needs brackets but -1, i.e. the unary minus operator does not
> here.
>
> Michael
>
> -------------------------------------------------------------------------
>    Prof. Dr. Michael Kohlhase,         Office: Research 1, Room 62
>    Professor for Computer Science      Campus Ring 12,
>    School of Engineering & Science     D-28758 Bremen, Germany
>    International University Bremen     tel/fax: +49 421 200-3140/-493140
>    http://www.faculty.iu-bremen.de/mkohlhase <m.kohlhase@iu-bremen.de>
> --------------------------------------------------------------------------
>
> juanrgonzaleza@canonicalscience.com wrote:
> > The chapter 4 of MathML 2.0 specification is far from precise at this
> > point.
> >
> > Moreover, the tutorial
> >
> > [http://cnx.org/content/m9008/latest/]
> >
> > recommends next code
> >
> >   <m:math>
> >     <m:apply>
> >       <m:minus/>
> >       <m:ci>x</m:ci>
> >     </m:apply>
> >   </m:math>
> >
> > to representing the negative of a variable, and recommends
> >
> > <m:math><m:cn>-1</m:cn></m:math>
> >
> > for the negative of a number.
> >
> > Whereas the next MathML tutorial
> >
> > [http://www.pragma-ade.com/general/manuals/mmlprime.pdf]
> >
> > says
> >
> > <blockquote>
> > Although <cn>-37</cn> is valid, using minus is sometimes more clear.
> >
> > <math>
> > <apply> <minus/>
> > <cn> 37 </cn>
> > </apply>
> > </math>
> > </blockquote>
> >
> > What is the difference if any between both encodings?
> >
> > What may be preferred? (I personally prefer unary usage of <minus/>)
> >
> >
> > Juan R.
> >
> > Center for CANONICAL |SCIENCE)

Received on Friday, 19 May 2006 15:53:50 UTC