On Thu, 05 Aug 2004 02:35:03 GMT, Bruce Ikenaga wrote:
On Wed, 04 Aug 2004 11:16:57 -0700, Harlan Grove wrote:

As for your TI calculator, either you're pressing the key sequence

3 [+/-] [x^y] 2 [=] which returns +9

or

3 [x^y] 2 [=] [+/-] which returns -9

In either case you're applying an unambiguous and manual operator
precedence. If you turn on a TI calculator or clear the register so it
shows 0, then press [+/-], the register still displays and contains 0
(zero), not -0, and when you then key in 3, it displays and contains
3. There's no way to represent leading minus signs with a TI
calculator. Your arguments would be more persuasive if it weren't so
obvious you were dreaming some examples up on the fly.

Your last sentence is ironic considering that you jumped to an
incorrect conclusion concerning the kind of calculator I was
using. But I accept responsibility for not giving the model
number. And no, I'm not into making up stuff to win arguments,
if that's what you mean.

All the TI calculators we support are graphical algebraic entry
calculators, and the one I had at hand (on which I tried the
example I gave) was a TI-82. You're describing the keypresses
for an old-fashioned "scientific" one-line display calculator, I
guess. On my 82, I press

(-) 3 ^ 2 <enter and get -9

or

(-) 3 <x^2 <enter and get -9

Here the (-) key is the unary minus key, <x^2 is the squaring key
which produces a power (superscript) 2, and <enter is the usual
<enter key. The first sequence produces the display "-3^2" before
<enter is pressed; in the second case, the "^2" is replaced by
a "real" power of 2.

And to add another data point, it is possible to duplicate this
computation on my HP48SX. I know what you're thinking; the HP
calculators use RPN. True, but the HP48 series calculators also have an
algebraic entry mode that allows you to enter

'-3^2' EVAL

which produces the result -9. As for that quoted expression, there
are at least two ways to enter it:

First method:
Press ' to enter algebraic mode, which produces '' and places
the insertion point between the quotes.

Press - (the subtraction sign).

Press 3.

Press the key marked y^x (y superscript x), which produces the
^ symbol.

Press 2.

Second method:
Same, except instead of pressing the subtraction symbol
followed by a 3, press 3 followed by the CHS (+/-) key.
Either way, the display reads '-3' at that point.

Thus, in this context, the unary minus and the binary minus are different
keys on the calculator but are interchangeable.


--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/index.cfm?action=book&bookid=228

"fred" wrote...
....
. . . I only draw from it that I was right in the first
place. The normal chalkboard, or academic math convention has been
deviated from. . . .

True.

. . . Some have given reasons for it like "since it's digital and it
can't hold a reciprocal it has to be that way" or something along those
lines. No one seems to really have any good reason.

More subtle: some people consider -3 unambiguously a single token
representing the reciprocal of 3. They generalize from that that -x is
unambiguously the reciprocal of x. Since "negative three" raised to the
second power is nine (+9), they figure that -x^2 should work similarly.

It's not standard, but it's not unreasonable, and it can be used
consistently. That there's then no point to y = -x^2 as opposed to y = x^2
doesn't matter to these people.

I'm sure it's as you say. The early coders just got it wrong and were
kind of stuck with it for legacy reasons. Sort of like the Y2K
situation a few years ago. Or the language applications just didn't
feel it necessary to get the order right, it was enough to just explain
in the reference manuals 'their' way of doing things.

More complicated. FORTRAN got it right from the beginning. Not surprising
since it was written by mathematicians and engineers. COBOL seems to have
been the first language to get it wrong. It was designed by business people
and the sainted Grace Hopper (note: I don't use emoticons to denote
sarcasm). They seem not to have been much concerned with the standard math
convention.

Like it or not, COBOL has been around a very long time, and there's still a
very large code base written in it. Excel, like it or not, followed COBOL's
convention. There's a very large 'code base' written in Excel. There's a
perception that it'd cost too much money to fix that code, and when
confronted by cost, business people ask "is the change necessary?" The
answer to that, like it or not, is *no*.

From my own development experience it's obvious to me that the reason
many of these people are holding some position that "it's just fine",
"that's the way it is", "user emptor", is that they don't have a lot
of math experience. . . .
....

Wrong. They just have real world experience in which cost is usually the
sole deciding factor. It costs less to teach prophylactic use of parentheses
than to change/correct these languages and application development systems
and all the code that runs under them. Also, many have experience with
Microsoft, its software and its attitude towards their own design decisions.
THIS IS NOT A BUG. FOR GOOD OR ILL, IT WAS INTENTIONAL. When Microsoft does
something on purpose, it stays done. See if you can detect any contrition in

http://support.microsoft.com/default...b;en-us;132686

To repeat: bitching, whining and moaning about this won't change a darn
thing. You are free to spend as much time engaged in these activities as you
like, but they'll be unproductive. Many people have learned the hard way the
futility of complaining about what Microsoft does and has done. Apparently
many more will have to learn the same lesson the same way.

. . . It's somewhat understandable in a language, but Excel is more
of an always-available do-everything super-calculator, not what I'd
consider a language. It should conform.
....

Why would it be more important for Excel, an end-user product *intended* to
be used by nontechnical people most of whom give less than a rat's back end
what mathematicians think, to adhere more strictly to standard conventions?
Why would it be OK for COBOL, some SQL variants and a few scripting
languages to retain this nonstandard operator precedence? If it's
'necessary' for one, it should be necessary for the other. OTOH, if the
world can cope with the languages remaining like this, it will continue
revolving about the sun if Excel remains unchanged.

Here's a little truth. Most people don't remember the operator precedence
they were taught in school. When in doubt, they look it up or test it out.

Here's an awkward bit of speculation. Now that computers have become nearly
ubiquitous in OECD countries, the great untutored masses now can calculate
on a daily basis. Perhaps this is a sign that most people either think the
existing convention isn't as useful as the Excel-like alternative or are
indifferent to the convention(s) employed in the software they use.

The world gets along just fine with driving on the left in some countries
and on the right in others. There's no obvious reason it can't also get
along with two broadly used operator precedence conventions as long as the
context governs the convention used. Current standard convention in
textbooks and articles, alternative used in 'business software'.

[In case you can't tell, I'm not being entirely serious in the last
paragraph, but other than a pathological need for rigid adherence to
orthodoxy, there's no necessary reason there must be one and only one
convention in use. It just means you need to check your convention before
using software. If there were one and only one notational form for inner
products, you all would have a stronger case for one and only one operator
precedence convention.]



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

JE McGimpsey wrote in message ...
In article ,
(Acid Pooh) wrote:

Uhm, sure. -x is "the number" in the relevant sense. But...

But only the relevant sense, eh? <g

the "x" in the expression "-x" is a variable. You can substitute one
variable for another and obtain a legal expression. Notice that I
didn't say "square x," or that if I were to have said "substitute x
by y^2," this would be a non-issue.

It wouldn't be a non-issue - your statements still depend on an
implicit order of operator precedence.

No, they don't. This is a simple substitution of variables. Let y be
a variable independent of x. Then we can substitute x - y^2 in the
expression x + (-x) = 0, since the expression is true for EVERY x.


Using your logic, strictly typographically, substitute x by y*2 in the
expression x^2.

y*2 isn't a term in the FOL. (y*2) is.


Are you arguing that the result is y*2^2 == y*4 (since I believe
everyone agrees that exponentiation has a higher precedence than
multiplication)??? If not, what would you do differently and why?

When you have a linear typographic notation with operators of different
precedence (e.g., Excel), one MUST use parentheses (or their equivalent)
to apply operations in the proper order.

Substitution of x by y^2 in the expression -x to produce -y^2 is *ONLY*
valid in a typographic system where exponentiation has a higher
precedence than monadic negation. If negation has higher precedence that
exponentiation, then the typographic substitution above is *only* valid
as

Uh... no, not really. Substitution of variables is often an axiom in
first-order languages. These languages apply to things much more
general than number systems.


-x == -(y^2)

Both are consistent typographical systems. Neither has any inherent
advantage over the other. Which you choose is, again, a matter of
convention.

To use that typography to argue for an implicit order of operator
precedence, that somehow your example resolves an ambiguity, is a
tautology, nothing more.

Stop being difficult. You asked for a citation and you got it. And
you got me to explain how substitution of variables work in the FOL.

'cid 'ooh

"fred" wrote...
....
or if you bought a car and noticed it was low on oil
and you topped it off and the pistons seized
and you later found out that this particular car
only uses synthetic oil and you should have checked
that out before you put oil in it.

If it stated unambiguously in the owners manual that this was so, and if
there were a warning on the dip stick or oil cap, it'd be entirely my own
fault.

or you bought an instant lottery ticket and
scratched off the boxes with a quarter
and won $20,000
and took it in, and they said you were supposed to
scratch if off with an "approved scratcher"
so your ticket is invalid.

If 4-point type in the back side of the ticket stated this requirement
clearly if nearly illegibly, again it'd be my own fault.

As for your first example, that's why lawyers make the big bucks.



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

"Stephen J. Herschkorn" wrote...
....
As I have noted before, this is incredible hubris on your part.

If I were the programmer who wrote this, you'd have a point. However, I'm
just a 'user' who's used this stuff long enough to know how to avoid
stepping in the metaphorical piles of dung.

If you use Microsoft software, you'd better read the documentation, or
you'll get bit in the butt. Complaining about how sore your butt is will get
you as much sympathy from Microsoft as the death cries of its erstwhile
competitors. Some of us learned to adapt to this state of affairs more
quickly than others.

Software professionals create tools to serve the client. . . .

There was precedent for the operator precedence convention Microsoft adopted
for Excel: COBOL. Maybe it only needs to be pointed out to a few
professional mathematicians that there was and is a lot of business software
written in COBOL, that some of the COBOL developers would become Excel
developers, and thus adopting the same operator precedence convention would
be rather an obvious thing to do in Excel. Do I need to make this simpler
for you to understand that Microsoft could have done *exactly* what you're
saying it should have done - serve the client? Or are you deluded enough to
believe that Microsoft considers the few thousand people who care about
'correct' operator precedence more important than the millions of users who
just don't care or may have become used to something else?

. . . It is *not* the responsbility of the client to adapt to the
programmers' sloppy design. . . .

They don't let you out into the real world much, do they?

If Microsoft were selling their services to no more than a few hundred
customers and faced serious competition, then you might have a point.
However, Microsoft sells millions of license units annually. The market has
voted: their customers are perfectly willing to adapt. I know it's hard for
some mathematicians to have to deal with empirical data, but you may get the
hang of it one day.

Documentation of this one exception does *not* excuse its
implementation, which surely causes undetected errors and/or generates
many hours spend on debugging.

Believe me, there are many other common sources of errors in Excel.

Anyway, to repeat something I've written before, as far as Microsoft is
concerned (and I'm not writing *for* them, I'm writing *about* them as a
long-time, interested observer) this is not a *BUG*. It's a design decision.
I agree that it's an unfortunate design decision, but bad designs that are
used in tens of millions of applications tend to remain unchanged. If you
don't understand why this is so, I can only suggest you seek out colleagues
in the Economics department who may be able to explain if for you.



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

And if that is really the case with Fred, then its just a question o
putting brackets at the appropriate place.

But, I think that instead of creating such a ruckus, it would have bee
wiser to post the bug, rather than wasting everyone's time.

- Manges

--
Message posted from http://www.ExcelForum.com

"Bruce Ikenaga" wrote...
....
Your last sentence is ironic considering that you jumped to an
incorrect conclusion concerning the kind of calculator I was
using. But I accept responsibility for not giving the model
number. And no, I'm not into making up stuff to win arguments,
if that's what you mean.
....

I appologize for that, and I'll take your word. I was assuming old fashioned
single number display calculators (no need for anything newer).



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

"Dik T. Winter" wrote in message ...
In article (Acid Pooh) writes:
"Dik T. Winter" wrote in message ...
In article (Acid Pooh) writes:
JE McGimpsey wrote in message ...
In article ,
(Acid Pooh) wrote:

I do believe that most posters in this thread know that. However,
while the meaning of -x may be clear, the meaning of -x^2 is not.

Substitute x^2 for x.

How does that clarify the meaning?

Well, since if I were substituting x+3 for x, the result would be
-(x+3)


Well, I suppose you mean you substituted (x + 3) for x.

Good. Substitute x+3 for x and we get -x+3. And so what?
It only shows that substitution without surrounding braces leads to
an expression that is quite different.

Well, my point here was that "x + 3" isn't strictly speaking a term in
the FOL, whereas "(x+3)" is. Neither is x^2, for that matter, but x^2
is usually taken to be abbreviated notation for (x*x). We can come up
with some nice abbreviated notation for (x + 3)--say, "z"--and
substitution yields -z.

So you substitute just one convention by another to clarify?

Yes. All languages are conventional.

But, given the context (a person asked me to justify the claim that
x^2 + (-x^2) = 0 from more-or-less the order axioms), I think the FOL
has primacy.


So what do you get if you substitute x^2 for x in "-x" ? Notice that
I didn't say "square x." For all it matters, I could have said
substitute y^2 for x. Or, if you'll allow me the convenience of
working in the reals, consider that x = "Sqrt(x)^2". More formally:
this is a substitution of _variables_ in the sense of the first order
logic. It doesn't matter what 'x' is in the formula x + (-x) = 0 is.
It might as well be "x^2." Kind of slippery, huh?

Yup, very slippery.

I'm sure you get it, but just to be clear, for the benefit of those
that don't: x + (-x) = 0 is an abbreviated notation for Ax(x+ (-x) =
0), where Ax means "for all x." A straightfoward application of
Universal Instantiation gives us the result.

'cid 'ooh

"Harlan Grove" writes:

"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

"This may lead to non-intuitive behavior;"
Joy joy.

MySQL's saner, which is what i use:
http://dev.mysql.com/doc/mysql/en/Op...recedence.html
Thou quite why bitwise XOR is so vastly higher in priority than
other bitwise operators, I have no idea.

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...
....
Thou quite why bitwise XOR is so vastly higher in priority than
other bitwise operators, I have no idea.
....

Maybe 'cause someone thought it was exponentiation.



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

"Harlan Grove" writes:

"Phil Carmody" wrote...
...
Thou quite why bitwise XOR is so vastly higher in priority than
other bitwise operators, I have no idea.
...

Maybe 'cause someone thought it was exponentiation.

The same deviant thought went through my mind.
However, I purged it quickly, as it made me nauseous

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)