Posts: 34
Threads: 9
Joined: Jan 2012
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 TI89s, when I came across a discussion comparing the TI89 to the HP50G. In the discussion, someone said that their little brother typed
2^4 {which is actually (2^4)}
into his TI84 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 HP35 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 HP35 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.)
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
Posts: 1,477
Threads: 71
Joined: Jan 2005
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.
Posts: 1,665
Threads: 142
Joined: Jan 2009
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.
Posts: 1,477
Threads: 71
Joined: Jan 2005
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.
Posts: 3,283
Threads: 104
Joined: Jul 2005
Katie, that's a good one. ;)
For those without access to a 30b: The result is a negative zero.
Posts: 171
Threads: 15
Joined: Sep 2011
Posts: 1,755
Threads: 112
Joined: Jan 2005
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 expressionevaluator call to it. I've got the commented ROM listing somewhere so I'll eventually check it up.
Best regards from V.
Posts: 536
Threads: 56
Joined: Jul 2005
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
Posts: 34
Threads: 9
Joined: Jan 2012
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
Posts: 10
Threads: 3
Joined: May 2011
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.
Posts: 1,477
Threads: 71
Joined: Jan 2005
That's not just a display of a negative zero, it's a whole new kind of number, one that does not equal zero.
Posts: 1,477
Threads: 71
Joined: Jan 2005
I like it, but my web browser doesn't do it justice.
Posts: 10
Threads: 3
Joined: May 2011
I just noticed that some browsers do not automatically wrap the text. I reformatted it. Try it now.
Posts: 1,477
Threads: 71
Joined: Jan 2005
Much more impressive looking!
Posts: 198
Threads: 17
Joined: Oct 2010
Calculated to 263,594 places. Impressive indeed but no more useful than Pi to an equally inordinate number of places. :)
Posts: 125
Threads: 9
Joined: Oct 2011
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.
Posts: 536
Threads: 56
Joined: Jul 2005
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
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
Posts: 3,283
Threads: 104
Joined: Jul 2005
At least it stops there while PI doesn't.
Posts: 1,477
Threads: 71
Joined: Jan 2005
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.
Posts: 3,283
Threads: 104
Joined: Jul 2005
Posts: 125
Threads: 9
Joined: Oct 2011
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.
Posts: 1,477
Threads: 71
Joined: Jan 2005
No 0 does not equal 0, maybe I just said that badly.
Posts: 3,229
Threads: 42
Joined: Jul 2006
0==0 is true on the 34S. In both integer and real modes.
 Pauli
Posts: 1,755
Threads: 112
Joined: Jan 2005
Quote:
0==0 is true on the 34S. In both integer and real modes.
Same thing with the HP71B:
> +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.
Posts: 73
Threads: 2
Joined: Sep 2011
All of this is specified in IEEE754 (for binary float) and IEEE854 (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.
