From: Leane Roffey <lroffey1@ix.netcom.com>

Date: Fri, 19 May 2006 10:57:27 -0500

Message-ID: <001101c67b5c$ed595460$0401a8c0@ozzie>

To: <R.W.Kaye@bham.ac.uk>

Cc: <www-math@w3.org>

Date: Fri, 19 May 2006 10:57:27 -0500

Message-ID: <001101c67b5c$ed595460$0401a8c0@ozzie>

To: <R.W.Kaye@bham.ac.uk>

Cc: <www-math@w3.org>

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

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