The elusive negative zero on the HP 30b

[EdS2]

Back in 2012, Katie Wasserman noted something unusual:

Quote:Try -55555 ^ -55555 on your 30b and tell me what you see.

The correct answer is a very small negative number which on most calculators will be rounded to zero. In this particular case - and it seems the 20b doesn't do it - the result is a displayed negative zero, which even tests as unequal to zero, although arithmetically it behaves as zero.

My questions would be
- what other calculations will return a negative zero?
- how did Katie find this one?
- why does the 30b do this? (and why doesn't the 20b)
- do any other HP calculators do this, or have any similar oddity?

Thanks to Bob for checking the 20b behaviour.

[Maximilian Hohmann]

Hello!

Tried it with some calculators that litter my desk:

HP20b: 0 (confirmed)
Ti Nspire CX: "Error: Overflow"
HP10s+: 0
HP35: flashing zero
HP67: 0
HP71B: Beep followed by "WRN:Underflow" followed by -1
HP25: Error
Ti Voyage 200: 0

So just one "-0" out of eight.

Regards
Max

[Marco Polo]

(05-10-2021 09:39 AM)EdS2 Wrote:  Back in 2012, Katie Wasserman noted something unusual:

Quote:Try -55555 ^ -55555 on your 30b and tell me what you see.

The correct answer is a very small negative number which on most calculators will be rounded to zero. In this particular case - and it seems the 20b doesn't do it - the result is a displayed negative zero, which even tests as unequal to zero, although arithmetically it behaves as zero.

My questions would be
- what other calculations will return a negative zero?
- how did Katie find this one?
- why does the 30b do this? (and why doesn't the 20b)
- do any other HP calculators do this, or have any similar oddity?

Thanks to Bob for checking the 20b behaviour.

- HP50g approx mode: 0 (flag -20 clear) or "Negative Underflow" (flag -20 set)
- HP50g exact mode: "integer too large"
- Free42 3.0.3 decimal (Win/Android): 0

[damaltor]

HP 11C and 15C: 0

[Jake Schwartz]

In double-precision mode, the wp34s returns zero also.
Jake

[Over_score]

WP43S returns -0. when the SPCRES system flag is set, 0. otherwise.

[damaltor]

I always thought that the 20b and 30b have the same firmware and differ only in the housing and buttons.

[Didier Lachieze]

No, in addition to the hardware differences there are software differences between the 20b and the 30b. The later has a solver, additional financial, prob and stat functions as well as a programming mode.

On this page you'll find a link to a review of the 30b from Gene highlighting the differences with the 20b.

[EdS2]

Yes, I too thought the 20b and 30b would behave the same, where they offer the same function. (I suppose we could dig into firmware versions: it's possible this behaviour isn't in all versions.)

Also interesting, I thought, that not all large negative odd numbers do the same... except, the behaviour seems slightly inconsistent. Previously I thought I'd found that -33333 and -11111 did not lead to minus zero - but today they do. Sometimes. It seems to depend a bit on the stack, or perhaps on some other state.

In fact, I think I'd even say the minus sign appears very briefly and is then removed, in cases where positive zero is returned. But that's debatable. (I remember very old calculators would do their trailing zero suppression just slowly enough to leave a visual impression.)

[FabioBrasil]

Here at HP30b the result was zero (no sign). At HP PRIME the result was a memory overflow.

[Thomas Okken]

(05-10-2021 12:07 PM)Marco Polo Wrote:  - Free42 3.0.3 decimal (Win/Android): 0

Free42 actually calculates -0, that's standard IEEE-754-compatible behavior. It just suppresses the sign when displaying the number, because the HP-42S doesn't do signed zero either. Also, 0 and -0 are always treated the same everywhere in Free42 anyway...

[EdS2]

(05-11-2021 04:30 PM)FabioBrasil Wrote:  Here at HP30b the result was zero (no sign)...

Interesting, because different! My SW Version is 4 5 2010, I wonder if yours is different. (One can check it with the On+PMT diagnostic menu.)

[EdS2]

(I should perhaps add, I was running in RPN mode.)

[FabioBrasil]

The SW version is the same: 4 5 2010 ²
Copyright 2048,000 HP Dev. C. L.P (c)
Algebric = 0 (no sign)
RPN = 0 (no sign)
Maybe it's because I use the "," and dd.m.yyyy as the decimal separator and the "."

ENGLISH
TVM STANDARD
ANNUAL
CAL.360
1,23
1.000,00
DEGREE

[rprosperi]

(05-12-2021 07:07 PM)FabioBrasil Wrote:  The SW version is the same: 4 5 2010 ²
Copyright 2048,000 HP Dev. C. L.P (c)
Algebric = 0 (no sign)
RPN = 0 (no sign)
Maybe it's because I use the "," and dd.m.yyyy as the decimal separator and the "."

ENGLISH
TVM STANDARD
ANNUAL
CAL.360
1,23
1.000,00
DEGREE

This has nothing to do with settings, I believe.

But it probably is because you are treating it like classic RPN and doing this:

55555 [+/-] [Input] [shift] [Y^X] => 0.00

While for Entry RPN (used on the 30B) you must do this:

55555 [+/-] [Input] 55555 [+/-] [shift] [Y^X] => -0.00

when using Entry RPN, you must enter a new number into X after pressing Input copies the original X into Y.

For example, if you do this:

5 [Input] [X]

you probably expect an answer of 25.00, but in fact you will get 0.00 (Try it!)

This is because in Entry RPN, the new number in X, after pressing [Input] is 0, so the "5 [Input] [x] is really doing 5 x 0 = 0.00

If you don't regularly use the 20b/30b, this seems odd. To me, this feels more like RPL, which in fact it is copied from.

[FabioBrasil]

This has nothing to do with settings, I believe.

But it probably is because you are treating it like classic RPN and doing this:

a) 55555 [+/-] [Input] [shift] [Y^X] => 0.00

While for Entry RPN (used on the 30B) you must do this:

b) 55555 [+/-] [Input] 55555 [+/-] [shift] [Y^X] => -0.00

I also think it has nothing to do with it. Perhaps that ² (from SW 4 5 2010 ²) explains something.
I did it both ways a) and b) and the result was 0,00

[rprosperi]

(05-12-2021 08:37 PM)FabioBrasil Wrote:  This has nothing to do with settings, I believe.

But it probably is because you are treating it like classic RPN and doing this:

a) 55555 [+/-] [Input] [shift] [Y^X] => 0.00

While for Entry RPN (used on the 30B) you must do this:

b) 55555 [+/-] [Input] 55555 [+/-] [shift] [Y^X] => -0.00

I also think it has nothing to do with it. Perhaps that ² (from SW 4 5 2010 ²) explains something.
I did it both ways a) and b) and the result was 0,00

You may be right... Checking my version again, the small raised number on the right edge is a 1.

So... maybe HP did consider this "-0.00" as an invalid, or at least undesirable, display and changed the f/w to prevent it.

[EdS2]

(In a previous thread, it was noted that the final small digit of the version string is the day-of-week, and it comes out different depending on the user's date format settings. The version string itself does not vary in appearance or meaning - it must be interpreted in factory-fresh format.)

Good point about the stack behaviour: we must press Input twice if we want to duplicate a freshly-entered number.

I just tried again and got the negative zero for both -55555 and -33333. Also -32767 so that's another theory falsified. And -16383.