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

You write: 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 ;-)
*****

I've worked with FORTH (back when the earth was cooling).
Less readable, perhaps, but if you were a FORTH user, they
were a breath of fresh air. I think you have a point here worth looking at.
(perhaps issued from the Bureau of Silly Random Walks :-)  )
Those work for simple expressions, there is no doubt.

The whole question of "greenfield" issues, like encoding
negative numbers often involves the assignment of multiple uses
to the same physical character. As I've seen before on this
forum, sometimes that's important to clarify, and other times it isn't.

I recently consulted for a nationally known tutoring center as a
mathematics specialist, and in examining the arithmetic for
grades K-12, found that for some time now, the children are
shown negative integers as the integer with a superscripted
 "minus sign" either in front or back of the number. It varied
by textbook.

 When presented then, with expressions like "some positive
number minus some negative number" or "some negative
number minus some negative number" the resulting confusion
was the stuff of legend. This concerned me because the
ultimate goal of content MathML, in my applications, would be to be able to
present interactive learning to any audience, integrating
both correct representation of intent by the user and ensuring the answer
would be correctly interpreted by any scripting compiler
running the page by any browser anywhere. Richard has
already pointed out the issues about browsers. Documentation,
for which both style and content would be important, for me, is
vital. Short of representing any negative integer by the mirror
image of its positive integer around zero, I can't think of any
way around this difficulty offhand.

Your points on compilers are well-taken. They are tricky devils,
depending on the language and how run-time oriented they are.
I could wax for hours on the differences, but that would really
be off topic for this thread.

Leane

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



----- Original Message -----
From: <juanrgonzaleza@canonicalscience.com>
To: <www-math@w3.org>
Cc: <lroffey1@ix.netcom.com>
Sent: Friday, May 19, 2006 12:14 PM
Subject: 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-fo
r.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.ht
ml]
>
> > 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:52:56 UTC