Re: [office-formula] Re: OASIS: Infix Operator "^"

["David A. Wheeler" <dwheeler@dwheeler.com>]

On Thu, 2007-22-02 at 21:09 +0200, Leonard Mada wrote:
> > Chapter 6.3.5 of the OASIS OpenFormula document (version 2007-02-14) 
> > describes the Infix Operator (^).
> > 
> > However, it contains a lot of mathematical ERRORS:

Andreas J. Guelzow
> Considering that the document contains definitions there is no claim
> that the terms match what others may define. Unfortunately there is a
> significant discrepancy of the normal mathematical definitions and what
> is used in spreadsheets.
> 
> In any case, OpenFormula describes the syntax used in a file. There is
> no absolute requirement that this is what the user sees. As noted below,
> Gnumeric includes aditional parentheses in case were precedence is
> unexpected.
> 
> [Of course there is an issue here: in OOo ^ appears to be
> left-associative while in Gnumeric it is right-associative.]
> > 
> > 1. ^ is left-associative, not right-associative!!!
...
> > 2. The classic ERROR: -4^2
> > Mathematically, this yields always -(4^2)=-16, NEVER +16!!!
> > There is NO unary operator in mathematics that converts a number to its 
> > negative, like described in the documents.

I'm very familiar with these traditional mathematical interpretations.  Indeed, early version s of this document had the reverse association, which was later perceived as a mistake and fixed.  The format we're defining is primarily for spreadsheets; silently changing precedence rules is dangerous and potentially deadly.

Spreadsheet applications generally agree that "=-2^2" computes as 4, and that "=2^3^4" is 4096.  Certainly both OpenOffice.org and Excel agree on that, and if I recall correctly, many other spreadsheet applications do as well.

Applications can show a different representation in their user interface if they want to, but in general we've tried to use a syntactic representation that is consistent with typical user interfaces.

 
> And inventing a syntax that break what historically has been done in the
> field (in this case in spreadsheets) isn't good for a standard either.

That's my view as well.  Where we CAN make changes to make the syntax more consistent with other conventions or standards, without silently making dangerous changes, we should do so.  But these precedence rules probably go all the way back to VisiCalc, and are nearly universally agreed-upon.

--- David A. Wheeler