W3C home > Mailing lists > Public > www-math@w3.org > May 2006

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

From: <juanrgonzaleza@canonicalscience.com>
Date: Fri, 19 May 2006 10:14:13 -0700 (PDT)
Message-ID: <3079.>
To: <www-math@w3.org>
Cc: <lroffey1@ix.netcom.com>

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


Leane Roffey wrote:
> 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.

Yes, this is the point I taken in the formal module of CanonML:


Not only the problem is on remember rules of precedence for a *few*
operators (of order of 50 rules for C++). Even remembering it often you
can find code is not doing you waited:


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

With systems containing thousands of commands and operators (C++ contains
only a trivial subset of mathematics/logic), which may be easily extended
brackets, parentheses or so are good.

A possibility for elimination of brackets is working only 2-ary operators
in postfix form. The code (a kind of infix LISP):

[Y \= [plus [times a \* x] \+ b]]

can be expressed in a FORTH-like way

a x * b + Y =

But last expression is less readable than Lot of Irritant Silly
Parentheses ;-)

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

Juan R.

Received on Friday, 19 May 2006 17:14:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:27:37 UTC