Hi everyone,
I was browsing the internet today, wondering why more of my fellow electrical engineering students won't learn RPN and stop using their TI-89s, when I came across a discussion comparing the TI-89 to the HP-50G. In the discussion, someone said that their little brother typed
-2^4 {which is actually -(2^4)}
into his TI-84 and got -16. This is right. If we type
(-2)^4,
the machine returns 16, also right.
The difference is obviously the parentheses.
WHAT DOES THIS ALL MEAN???
All I have to do with an RPN machine is 2 CHS ENTER 4 Y^X.
SO, I pulled out my trusty HP-35 and tried it!
I pressed:
4 ENTER 2 CHS X^Y (That should do -2^4 = -16 right?)
BUT, to my surprise, the display flashed a big fat ZERO at me!
Why is this? Why does the HP-35 refuse to take a negative number to a power?
I can understand if the power were fractional, such as (-2)^(1/2), resulting in the square root of negative 2.
But the calculator won't do ANY negative number to ANY positive or negative power!
(My 50G can do this just fine.)
I looks like it always uses logs and exponentials to compute powers and doesn't perform a check for integer exponents. My 30b and the 15C LE both handle the integer case correctly.
The 35 was really simple and had limited ROM space so they coded x^y as exp(y * ln(x)). Thus if x is zero or negative the ln function will result in the flashing zero -- the error indicator. This is true for many of the early scientific calculators.
Actually, this is a problem for all the HP Classics as well as some of the Woodstocks (HP 21 and HP 25). In fact, the HP 55 returns 4 as the result, instead of 16. By the time the Spices were introduced, the problem had been solved, and all later calculators work properly with negative numbers raised to a power.
Edited: 24 Jan 2012, 11:45 a.m.
Quote:
My 30b and the 15C LE both handle the integer case correctly.
I'll bet not. Try -55555 ^ -55555 on your 30b and tell me what you see.
Katie, that's a good one. ;-)
For those without access to a 30b: The result is a negative zero.
Quote:
The 35 was really simple and had limited ROM space so they coded x^y as exp(y * ln(x)).
The venerable ZX Spectrum of lore did even worse, as it computed Sqrt(x) as x^0.5, which in turn was computed as exp(0.5*ln(x)), thus needing two transcendental functions (and one multiplication), which made the square root function one of the slowest mathematical operations available while with a proper implementation it would be about as fast as a simple division.
If I remember correctly, the ROM code simply pushed x and 0.5 to the math stack and then either fell straight into the x^y routine or made an expression-evaluator call to it. I've got the commented ROM listing somewhere so I'll eventually check it up.
Best regards from V.
modern calculators should also handle certain rational power cases.
for example (-32)^(3/5) = -8
there are, of course, the complex answers which are also correct mathematically, but i always like to see the real result given if it exists - especially on calculators without complex numbers!
the above example should also work as (-32)^0.6 = -8
Quote:
The 35 was really simple and had limited ROM space so they coded x^y as exp(y * ln(x)). Thus if x is zero or negative the ln function will result in the flashing zero -- the error indicator. This is true for many of the early scientific calculators.
Thank you Katie, that's just what I wanted to know.
I figured it had to be an algorithm/coding type issue, as that is the area of the calculator I know the least about!
Thanks to everyone who participated in this discussion, you have justified the three hours I spent talking to myself saying,
"WHY WON'T IT DO THAT?!"
-Dan Lewis
Being an incurable Smart Alec, I took Katie Wasserman's -55555 ^ -55555 as a challenge. I evaluated it to an exact proper fraction:
-1/12436709…248046875
Which turns out to be around four printed pages long. If anyone wants to see the entire number it is at:
http://home.earthlink.net/~zcave/longnum.txt
Of course I calculated it by hand. Well -- not really. I used Python which has unlimited precision integers. This works out because I could rearrange it like this: -55555 ^ -55555 becomes -1/(55555^55555).
If you want to try it yourself, run the following in your favorite terminal application, assuming you have Python installed. Any UNIX or UNIX like operating systems such as Mac OS X or Linux should already have it. If you are running Windows, first, my condolences. Second, you can install it for free. (http://www.python.org/)
python -c "print '-1/%d' % 55555**55555" > longnum.txt
This could also be calculated using "bc", since it too has unlimited precision integers.
That's not just a display of a negative zero, it's a whole new kind of number, one that does not equal zero.
I like it, but my web browser doesn't do it justice.
I just noticed that some browsers do not automatically wrap the text. I reformatted it. Try it now.
Much more impressive looking!
Calculated to 263,594 places. Impressive indeed but no more useful than Pi to an equally inordinate number of places. :-)
Quote:
for example (-32)^(3/5) = -8
there are, of course, the complex answers which are also correct mathematically, but i always like to see the real result given if it exists - especially on calculators without complex numbers!
The HP15c LE returns an Error 0 for the
32 CHS [enter] 3 5 / y^x
calculation in real mode so I tried it using Wolfram Alpha with the input:
(-32)^(3/5) real
"Input interpretation:
is (-32)^(3/5) a real number?
Result:
(-32)^(3/5) is not a real number
Decimal approximation(split over 3 lines):
-2.4721359549995793928183473374625524708812367192230514485...
+
7.6084521303612285769315146670350571472455890730060017795... i "
which is the same to 8 dp as the HP15c gives in complex mode.
Nick
Edited: 25 Jan 2012, 2:20 a.m.
unfortunately Alpha is not completely correct in saying "Result: (-32)^(3/5) is not a real number". There are, of course, 5 solutions to this calculation, four complex ones and one real one. calculators giving complex answers are just as correct mathematically, but it's nice to give a real output answer to a real input question, whenever it exists.
(-32)^(3/5) = ((-32)^3)^(1/5) = (-32768)^(1/5)
so, all 5 fifth roots are correct answers. ie the solutions to x^5 + 32768 = 0
However, since complex roots appear in conjugate pairs, there must be one real solution.
namely,
(-32)^(3/5) = ((-32)^(1/5))^3 = (-2)^3 = -8
From what I have tested it's 0, at least if used in any simple arithmetic (*, +). If you have two of these in x and y then ?= returns 1. If you have -0 in y and 0 in x then ?< returns 1.
This looks like a negative zero to me.
At least it stops there while PI doesn't.
If you have -0 in x and 0 in y ?= will return 0. So it's not zero, it's less than zero yet it will work exactly like 0 if used in arithmetic. A pretty strange number if you ask me.
Thanks, if I feed Alpha the expression x^5 + 32768 directly as input then it does indeed produce all five roots:
Real root:
x = -8
Complex roots:
x = 8 (-1)^(1/5) ~~ 6.47214 + 4.70228 i
x = -8 (-1)^(2/5) ~~ -2.47214 - 7.60845 i
x = 8 (-1)^(3/5) ~~ -2.47214 + 7.60845 i
x = -8 (-1)^(4/5) ~~ 6.47214 - 4.70228 i
together with a nice star plot of the roots in the complex plane.
Nick
Edited: 26 Jan 2012, 7:01 a.m.
No -0 does not equal 0, maybe I just said that badly.
-0==0 is true on the 34S. In both integer and real modes.
- Pauli
Quote:
-0==0 is true on the 34S. In both integer and real modes.
Same thing with the HP-71B:
> +0=-0
1
However, some functions do treat them differently even though they test equal so -0 it's not just for show.
Best regards from V.
All of this is specified in IEEE-754 (for binary float) and IEEE-854 (later, for binary and decimal float and others).
[As an aside, note that calculators generally use decimal floating point math, so that 0.1 is an exact number. PCs and other systems (using a C math library, etc.) often use binary floating point math, where the mantissa is binary and the exponent is a power of 2. In these systems, 0.1 decimal is a repeating binary fraction that cannot represent 0.1 exactly, so 0.1 * 10.0 results in a number slightly less than 1.0 (0.9999998 for example).]
I have a fair amount of experience with binary float --- less so with decimal. But I think what follows still applies...
In single precision binary float, +0 is the bit pattern:
0_00000000_00000000000000000000000
(sign, exponent, mantissa all zero bits)
and -0 is the bit pattern:
1_00000000_00000000000000000000000
(negative sign, but exponent and mantissa still all zero).
IEEE says that -0 and +0 must compare equal, but many systems take the shortcut of comparing the underlying bit patterns and will result in 'not equal'. (These systems generally are coded to NEVER generate -0, sort of as a "workaround" -- so you'll never have to compare a -0 -- but a -0 received over a comm link will mess them up.)
IEEE 754 also has bit patterns for +/-Infinity, Indefinite, and both "signaling" and "quiet" NaNs (Not a Number). If a variable "x" has NaN (any) for a value, IEEE says x==x should compare FALSE (a NaN never compares equal to anything), but in a system which only compares the underlying bit patterns, x==x will compare TRUE, even if x is NaN.
So is -0==0? Not if the float library was written for speed at the expense of compliance with standards.