Lance Lamboy wrote:

....
I checked my copy of oocalc. (I don't use M$ products.) Much to my
chagrin it exhibited the same Excel bug.

Historically speaking, I wouldn't put the blame on Microsoft. You can
download a working copy of the original release of VisiCalc from
http://www.bricklin.com/history/vcexecutable.htm
and verify that it worked the same way. I presume that all subsequent
versions of VisiCalc used the same order of operator precedence to avoid
breaking existing applications. I do not have access to a version of
Lotus, but I presume that they utilized the same order of operator
precedence to make it easier for people to switch from VisiCalc to
Lotus. MS probably adopted the same design decision for the same
reason, when they competed with Lotus (just as they preserved the Lotus
mistake of considering 1900 to be a leap year).

The 1900 Leap Year is clearly wrong, but it would have created far more
problems if dates did not import correctly from Lotus spreadsheets, than
to keep existing aps working and warn users that the date system
included a nonexistent date.

However, to call clearly documented operator precedence decisions a
"bug" stretches the definition considerably, since precedence is a just
a convention that attempts to resolve ambiguous expressions. If you are
that concerned about it, then don't write ambiguous expressions -- that
is what parentheses are for.

Jerry

"Jerry W. Lewis" wrote...
Lance Lamboy wrote:
...
I checked my copy of oocalc. (I don't use M$ products.) Much to my
chagrin it exhibited the same Excel bug.

Historically speaking, I wouldn't put the blame on Microsoft. You can
download a working copy of the original release of VisiCalc from
http://www.bricklin.com/history/vcexecutable.htm
and verify that it worked the same way. I presume that all subsequent
versions of VisiCalc used the same order of operator precedence to avoid
breaking existing applications. I do not have access to a version of
Lotus, but I presume that they utilized the same order of operator
precedence to make it easier for people to switch from VisiCalc to
Lotus. . . .

And you'd be wrong! In 123, -3^2 returns -9.

. . . MS probably adopted the same design decision for the same
reason, when they competed with Lotus (just as they preserved the Lotus
mistake of considering 1900 to be a leap year).
....

While Lotus is unquestionably to blame for the 1900-as-leap-year bug,
Microsoft actually chose to have Excel behave DIFFERENTLY than 123 in the
beginning. Now in the beginning there was only Excel for the Mac, and 123
only existed for 8086/8-based PCs, so there may have been no perceived need
for Excel to duplicate 123's operator precedence. However, once established
in the Mac world, it would have become a practical impossibility to do
anything different on PCs.

Microsoft gets all the credit/blame for aping VisiCalc rather than 123.



Posted Via Nuthinbutnews.Com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.nuthinbutnews.com

Harlan Grove wrote:

"Jerry W. Lewis" wrote...

Lance Lamboy wrote:
...

I checked my copy of oocalc. (I don't use M$ products.) Much to my
chagrin it exhibited the same Excel bug.

Historically speaking, I wouldn't put the blame on Microsoft. You can
download a working copy of the original release of VisiCalc from
http://www.bricklin.com/history/vcexecutable.htm
and verify that it worked the same way. I presume that all subsequent
versions of VisiCalc used the same order of operator precedence to avoid
breaking existing applications. I do not have access to a version of
Lotus, but I presume that they utilized the same order of operator
precedence to make it easier for people to switch from VisiCalc to
Lotus. . . .


And you'd be wrong! In 123, -3^2 returns -9.

Interesting and surprising. Thanks for the information.

Jerry

"Jerry W. Lewis" wrote...
Harlan Grove wrote:
"Jerry W. Lewis" wrote...
....
. . . I do not have access to a version of
Lotus, but I presume that they utilized the same order of operator
precedence . . .

And you'd be wrong! In 123, -3^2 returns -9.

Interesting and surprising. Thanks for the information.

Purely for the sake of argumentativeness, why surprising? It had to
return -9 or +9, and given the precedence in most programming
languages that provide both unary minus and exponentiation operators
-9 would be more common. Indeed, in VBA -3^2 returns -9.

Conformity with VisiCalc wasn't a good idea. VisiCalc was APL in
reverse - all left to right evaluation. For example, 2*3^4 = (2*3)^4
rather than 2*(3^4), and 2+3*4 = (2+3)*4 rather than 2+(3*4). Just as
in APL, and for the same reason, this is UNAMBIGUOUS.
Counterintuitive, perhaps, but unambiguous. If Excel also enforced
left to right evaluation with no operator precedence and only
parentheses to change evaluation order, then Excel could claim
consistency with VisiCalc, FWLIW. It doesn't, so Microsoft can't claim
conformity with either VisiCalc or 123 to support their choice of
operator precedence. They came up with this all on their own.

That Lotus chose to have 123 behave differently than VisiCalc was a
good thing, IMO. OTOH, Microsoft Excel is aking to COBOL rather than
FORTRAN. How nice!

That said, at least in the context of programming languages, in which
various spreadsheets' formulas are functional languages, there's no
consistent convention for operator precedence. Whether or not this
is/was a mistake is irrelevant to the extent that changing it would be
worse. In any case, this is *not* a bug in Excel, it's a feature
arising from a possibly obtuse design decision.

So far 4 different parsing approaches in spreadsheets and programming
languages have been described: APL's no precedence, strict right to
left; VisiCalc's no precedence, strict left to right; the mainstream's
(123, FORTRAN, BASIC including VBA, Perl, Python, etc.) exponentiation
taking higher precedence than negation; and the fringe's (Excel,
COBOL, apparently AppleScript, REXX and a few others) negation taking
higher precedence than exponentiation.

At the very least, no matter what may be correct in textbooks, there's
ample variety in programming languages, so anyone attempting to use
any programming language to perform calculations on a digital computer
had better check their programming language's operator precedence.
Bitching, whining and moaning about how this is wrong, wrong, terribly
wrong is wasted time, breath and effort.

"Harlan Grove" wrote

in VBA -3^2 returns -9.

I agree with your attitude as stated below, but it sure seems like an
inconsistency when "Cells(1,1)=-3^2" in an Excel macro (VBA) makes the
cell-value -9, while typing "=-3^2" in the cell makes the cell-value 9.
It's the seeming *inconsistency* that's the problem.

At the very least, no matter what may be correct in textbooks, there's
ample variety in programming languages, so anyone attempting to use
any programming language to perform calculations on a digital computer
had better check their programming language's operator precedence.
Bitching, whining and moaning about how this is wrong, wrong, terribly
wrong is wasted time, breath and effort.

--r.e.s.

"r.e.s." wrote...
....
I agree with your attitude as stated below, but it sure seems like an
inconsistency when "Cells(1,1)=-3^2" in an Excel macro (VBA) makes the
cell-value -9, while typing "=-3^2" in the cell makes the cell-value 9.
It's the seeming *inconsistency* that's the problem.

Agreed, it's a problem. However, it was unavoidable. BASIC existed long
before any spreadsheet, and BASIC had established operator precedence
(mainstream). Excel existed before VBA, a dialect of BASIC, was grafted onto
it, and the nice people at Microsoft made a bad (but irrevocable in
practical terms) design decision about operator precedence. (Does anyone
know how Multiplan handled -3^2?)

When the two, Excel and VBA, were merged, the inconsistency became truly
exquisite. Excel also uses a sign convention in its financial functions,
something none of the non-Excel clone spreadsheets (so few these days) do or
did. Indeed, there are a lot of questionable design decisions in Excel, but
at this point in time you have to live with them or use something else.



Posted Via Nuthinbutnews.Com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.nuthinbutnews.com

"Harlan Grove" wrote
When the two, Excel and VBA, were merged, the inconsistency became truly
exquisite.
Indeed, there are a lot of questionable design decisions in Excel, but
at this point in time you have to live with them or use something else.

IMO this sort of inconsistency is symptomatic in many ways of Microsoft's
software engineering - although I do accept it is quite possibly an industry
wide malaise rather than MS specific.

When the issue was first identified the bitter pill should have been
swallowed and the "problem" fixed. Sure there would have been some grief,
but it would have been a lot less than would arise were an attempt made to
address it today.

This lack of guts (ie.expediency rules over rationality) IMO underpins the
even more "exquisite" hacks on IE and other products - it makes the
Trustworthy initiative quite laughable because the focus seems not to
unequivocally fix the problems at the source, but to determine the most
expedient way to neutralise a threat by working out which objects can be
trusted to what degree. Sure defensive coding is desirable in each and
every object, but that is never a justification to leave an aberrant object
untouched.

Apols for the sermon, Frank.

On Tue, 3 Aug 2004 19:29:08 -0700, "Harlan Grove" wrote:

(Does anyone know how Multiplan handled -3^2?)

According to my Multiplan 4.2 manual, the order is

"Sign (in other words, whether the number is positive or negative)
Percentage
Exponentiation
Multiplication and Division
Addition and Subtraction
Logical operations"

which, I believe, is the same as Excel, no? So -3^2 would be +9.

"r.e.s." writes:
"Harlan Grove" wrote

in VBA -3^2 returns -9.

I agree with your attitude as stated below, but it sure seems like an
inconsistency when "Cells(1,1)=-3^2" in an Excel macro (VBA) makes the
cell-value -9, while typing "=-3^2" in the cell makes the cell-value 9.
It's the seeming *inconsistency* that's the problem.

OMFG!

Now that _is_ a problem. I don't know whether to laugh or cry.

I store all my tables in a RDBMS, so I'll laugh.

Phil
--
1st bug in MS win2k source code found after 20 minutes: scanline.cpp
2nd and 3rd bug found after 10 more minutes: gethost.c
Both non-exploitable. (The 2nd/3rd ones might be, depending on the CRTL)

"Phil Carmody" wrote...
....
Now that _is_ a problem. I don't know whether to laugh or cry.

I store all my tables in a RDBMS, so I'll laugh.
....

Laugh all you want, Postgresql shares this operator precedence.

http://www.postgresql.org/docs/7.2/i...recedence.html



Posted Via Nuthinbutnews.Com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.nuthinbutnews.com