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

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

<lroffey1@ix.netcom.com>

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:

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

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:

[http://gcc.gnu.org/onlinedocs/gcc-3.2.3/cpp/Operator-Precedence-Problems.html]

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

Center for CANONICAL |SCIENCE)
```

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