The elusive negative zero on the HP 30b
05-10-2021, 09:39 AM
Post: #1
 EdS2 Senior Member Posts: 595 Joined: Apr 2014
The elusive negative zero on the HP 30b
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.
05-10-2021, 10:24 AM
Post: #2
 Maximilian Hohmann Senior Member Posts: 1,302 Joined: Dec 2013
RE: The elusive negative zero on the HP 30b
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
05-10-2021, 12:07 PM (This post was last modified: 05-11-2021 07:09 AM by Marco Polo.)
Post: #3
 Marco Polo Member Posts: 278 Joined: Jun 2016
RE: The elusive negative zero on the HP 30b
(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
05-10-2021, 12:49 PM
Post: #4
 damaltor Member Posts: 253 Joined: Dec 2015
RE: The elusive negative zero on the HP 30b
HP 11C and 15C: 0
05-10-2021, 05:39 PM
Post: #5
 Jake Schwartz Senior Member Posts: 355 Joined: Dec 2013
RE: The elusive negative zero on the HP 30b
In double-precision mode, the wp34s returns zero also.
Jake
05-10-2021, 06:28 PM
Post: #6
 Over_score Junior Member Posts: 12 Joined: Jul 2018
RE: The elusive negative zero on the HP 30b
WP43S returns -0. when the SPCRES system flag is set, 0. otherwise.
05-11-2021, 06:05 AM
Post: #7
 damaltor Member Posts: 253 Joined: Dec 2015
RE: The elusive negative zero on the HP 30b
I always thought that the 20b and 30b have the same firmware and differ only in the housing and buttons.
05-11-2021, 07:19 AM
Post: #8
 Didier Lachieze Senior Member Posts: 1,641 Joined: Dec 2013
RE: The elusive negative zero on the HP 30b
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.
05-11-2021, 07:20 AM
Post: #9
 EdS2 Senior Member Posts: 595 Joined: Apr 2014
RE: The elusive negative zero on the HP 30b
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.)
05-11-2021, 04:30 PM (This post was last modified: 05-11-2021 04:43 PM by FabioBrasil.)
Post: #10
 FabioBrasil Junior Member Posts: 14 Joined: Dec 2020
RE: The elusive negative zero on the HP 30b
Here at HP30b the result was zero (no sign). At HP PRIME the result was a memory overflow.
05-11-2021, 06:57 PM
Post: #11
 Thomas Okken Senior Member Posts: 1,893 Joined: Feb 2014
RE: The elusive negative zero on the HP 30b
(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...
05-12-2021, 06:37 AM
Post: #12
 EdS2 Senior Member Posts: 595 Joined: Apr 2014
RE: The elusive negative zero on the HP 30b
(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.)
05-12-2021, 07:01 AM
Post: #13
 EdS2 Senior Member Posts: 595 Joined: Apr 2014
RE: The elusive negative zero on the HP 30b
(I should perhaps add, I was running in RPN mode.)
05-12-2021, 07:07 PM
Post: #14
 FabioBrasil Junior Member Posts: 14 Joined: Dec 2020
RE: The elusive negative zero on the HP 30b
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
05-12-2021, 08:17 PM (This post was last modified: 05-12-2021 08:23 PM by rprosperi.)
Post: #15
 rprosperi Super Moderator Posts: 6,345 Joined: Dec 2013
RE: The elusive negative zero on the HP 30b
(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.

--Bob Prosperi
05-12-2021, 08:37 PM
Post: #16
 FabioBrasil Junior Member Posts: 14 Joined: Dec 2020
RE: The elusive negative zero on the HP 30b
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
05-12-2021, 10:41 PM
Post: #17
 rprosperi Super Moderator Posts: 6,345 Joined: Dec 2013
RE: The elusive negative zero on the HP 30b
(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.

--Bob Prosperi
05-13-2021, 07:55 AM
Post: #18
 EdS2 Senior Member Posts: 595 Joined: Apr 2014
RE: The elusive negative zero on the HP 30b
(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.
 « Next Oldest | Next Newest »