# HP Forums

Full Version: HP-35 powers with negative numbers
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

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.

;) Sweet!

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:

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.

Is -0==0 ? I doubt it.

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.