Fri, 4 Jan 2008 21:38:11 -0500 from Stan Brown
<the_stan_brown@fastmail.fm>:

Whoops!  C and C++ don't have an exponentiation operator. I've been
away from programming longer than I thought!

But again, VBA gives exponentiation higher priority than unary minus,
and that matches algebraic convention. It's too bad that Excel is
different.

Check the correction. I'm a little "late night challenged" here,
it's close to midnight. <g>

Regards
Martin

I just got to this thread and was about to post the same thing. A similar
question about operator precedence was asked just yesterday over in one of
the "compiled VB" newsgroups and the fact that exponentiation (in VB/VBA)
has a higher precedence than the negation was posted back as an answer to
the OP there. It would not have occurred to me that in an Excel spreadsheet,
a different operator precedence might be in use. Nice going Microsoft.<g>

Rick

In the first "real math program"ming language, IBM Mathematical
FORmula TRANslating System (FORTRAN), unary minus has precedence over
exponentiation.

Precedence is not determined by the order in which an expression is
"read" (parsed).  Operators associate either left or right; and any
parser can do either.  For example, Excel has no problem interpreting
1 + 2 * 3 as 1 + (2*3).  Likewise, Excel could just as easily
interpret - 10 ^ 2 as -(10^2) if it wanted to.

It is simply the choice of the MS Excel designers that unary minus has
higher precedence than exponentiation.  Actually, it is probably the
designers of Visicalc who made that decision; the designers of Lotus
followed suit for compatibility reasons; and the Excel designers
followed Lotus for the same reason.

Don't confuse a tech writer's use of terminology with the canonical
use.  In the good ol' days, computer tech writers were experts in the
disciplines that they wrote about.  Nowadays, the tech writer is
usually an English major who often has no in-depth knowledge of --
sometimes not even much experience with -- the subject.  I have first-
hand knowledge of that fact.

I do not believe that "negation" or "complement" is used exclusively
in one discipline or the other.  I don't know of any engineer who
describes the signal x-bar (that is, x with a line over it) as "the
negation of x"; it is the complement (or inverse) of x.  On the
flipside, mathematicians universally refer to -x as "negative x".  So
I can understand why someone might call the "-" symbol in that context
as "negation".

On the other hand, I would never refer to the binary "-" and "+" as
"subtraction" and "addition".  Those are their operation; but the
symbols are "minus" and "plus".  Similarly, I call the unary "-"
simply "unary minus".

In a math text, you would find 2 (superscript) 3 (superscript) 4,
which is unambiguous.  If you interpreted that as 2^3^4 instead of
2^(3^4), the error would be yours, not Excel's.

It is the same with any translation between two languages -- say
English and Chinese.  If the translated text does not match the
intended meaning of the original text, the error is in the
translation.  No one would say that one or the other language is
"wrong".

What you do not seem to grasp is the difference between ambiguous and
unambiguous representations.  Computer language representation of
mathematical formulas -- at least what we are discussing here -- is
inherently ambiguous.  We rely on rules and special syntax (e.g.
parentheses) to resolve those ambiguities.  No one set of rules is
right or wrong.

For computer programs, assumptions about operator precedence have always been
subject to "caveat emptor" ("let the buyer beware"), and parentheses should
be used liberally unless the user is certain of the order that particular
program will perform the operations.  I recently used a programming language
that, consistent with its rules, evaluated 2*3+4*5 to be 50=((2*3)+4)*5
instead of 26=(2*3)+(4*5); if I had read its documentation on order of
operations, I would not have been caught by surprise.

Excel performs consistently with its published documentation about operator
precedence, so calling it "wrong" is questionable, although I agree that
giving unary negation a higher precedence than exponentiation is unusual (and
has resulting in some unwarranted published criticisms about Excel not being
able to handle some standard nonlinear least squares problems using Solver).

I can't recall ever seeing in mathematical literature an expression as
ambiguous as 2^3^4; it would usually be disambiguated by parentheses.  
Waterloo Maple (a real Math program) will not evaluate it at all; version 11
returns a message "Error, ambiguous use of '^', please use parentheses",
earlier versions just said "Error, '^' unexpected".

Jerry

I have looked at a lot of mathematical literature in my lifetime, and
I do not recall any that uses "^" for exponentiation.  In fact, "^" is
not even used universally in programming languages to mean
exponentiation.  Of course, "^" means bitwise XOR in C and its
derivatives; it means "pointer to" in Pascal.  In the first IBM
Mathematical FORmula TRANSlating System (FORTRAN), "**" is used for
exponentiation.  In the original Dartmouth BASIC, an up-arrow was used
for exponential.  (Up-arrow was actually a key -- shift-N -- on ASR-33
teletypes, which did not have "^".)

(Admittedly, I am not familiar with specifically mathematical
programming languages and libraries and their associated
documentation, which might be what Jerry intended to refer to.)

In mathematics, exponentiation is represented by a superscripted
expression.  Of course, superscripting disambiguates the meaning of -x
(superscript) y because of the convention in mathematics of applying
the superscripted expression to the constant or variable immediately
to the left.  And I am sure that __that__ is the "thinking behind"
giving exponentiation higher precedence than unary minus in those
programming languages that do and that use "^" (or up-arrow),
presumably being interpreted as "superscript".

Arguably, another possible explanation is that -x^y is mathematically
equivalent to 0 - x^y.  In that case, "^" almost universally has
higher precedence over the binary "-", at least in programming
languages that have precedence.  But that reasoning would not readily
lead to a reasonable interpretation of x^-y.  On the contrary, using
similar reasoning, that would have to be explained as x^(0 - y); and
by extension, -x^y might then be explained as (0 - x)^y, which leads
to the Excel interpretation.  Klunk!  Ergo, advocates of -(x^y) as the
only "right" interpretation would do well to stick with the first
(hieroglyphical) explanation above.

FYI, in Dartmouth BASIC, x^y^z (using "^" here to mean up-arrow) was
interpreted as (x^y)^z, just as it is in Excel.  (This comment is
really in reference to a comment that Dana DeLouis made.)
Interestingly, in Dartmouth BASIC, exponentiation was defined for only
non-negative values.  What I really mean is:  x^y was defined to mean
abs(x)^y.  I'm sure the reason has more to do with the ease of
implementation of the BASIC interpreter than with any mathematical
principle ;-).