You think that's bad? I once reported a bug in Apple's calculator in OS X, and it was fixed by the next release.
If you started out with a cleared calculator with default settings and computed 14479.14 - 152.36 you got 14326.78.
If you started out with a cleared calculator with default settings and computed 1143/78, and then computed 14479.14 - 152.36, you got something like 14326.779999999999.
The number of people on forums who completely missed the point and lectured me, often rather condescendingly, on how neither 14479.14 nor 152.36 are exactly representable in finite binary floating point and so that is why the subtraction was not exact was astonishing.
The bug is not that the subtraction is inexact. The bug is that the same subtraction result was displayed with different rounding depending on whether it was done immediately after a clear or done after computing 1143/78.
How 14479.14 - 152.36 displays should only depend on the calculator settings. That it changed depending on previous calculations suggest that there was probably a scratch variable used during calculations that was supposed to be reset before the next calculation but was not.
Speaking of the MacOS calculator, their RPN mode really annoys me (although not as much as Windows 10 calculator which doesn't even have an RPN mode!). Suppose you want to compute (2+3) x 4. The obvious key sequence works: 2 enter 3 + 4 x.
How about (2+3) x pi. The obvious key sequence is: 2 enter 3 + pi x. The result of that is an error beep with pi in the display, or, if you had anything on the stack before you started, that thing multiplied by pi.
That's because rather than pushing pi onto the stack, the pi key replaces whatever is on the bottom of the stack with pi. In other words, instead of acting as if you had hit the keys 3 . 1 4 1 5 9 ... 7 9 3, it acts as if it pops the stack, invokes the function
def pi(x):
return 3.141592653589793
on the value it popped, and pushes the result.
What you have to do is: 2 enter 3 + enter pi x.
Suppose you decide you don't want to have to remember the distinction between the pi key and numerical entry, and decide to just always put in that enter.
So: 2 enter 3 + enter 4 x. That gives you 20 like you would expect...but also leaves a 5 on the stack above that.
For comparison, that does not happen on an HP-15, or on software calculators that follow HP RPN rules, such as pcalc on iOS. On those, when you press enter it duplicates the item currently on the top of the stack, just like Apple's calculator, but it sets a flag that says if you immediately enter a number, that overwrites the top of stack instead of pushing.
This flag was a key thing that made data entry on the HP calculators feel natural.
On the HP-48 they made a significant change to this. When you pressed enter it did not immediately dup the stack and set the flag saying numerical entry should overwrite. Instead, pressing enter did not immediately do anything to the stack. Instead, it set a flag saying that if your next action was to enter a number, first dup the top of stack.
The RPN mode on pcalc lets you select if you want HP-48 stack behavior or classic RPN behavior (it is in advanced settings when you are in RPN mode).
How 14479.14 - 152.36 displays should only depend on the calculator settings. That it changed depending on previous calculations suggest that there was probably a scratch variable used during calculations that was supposed to be reset before the next calculation but was not.
...and my guess is that "scratch variable" is actually a flag that switches calculations between fixed-point and floating-point mode; the first subtraction was done in fixed-point mode, but when it did the division it used floating-point, and then kept that mode for future calculations until explicitly cleared.
If you started out with a cleared calculator with default settings and computed 14479.14 - 152.36 you got 14326.78.
If you started out with a cleared calculator with default settings and computed 1143/78, and then computed 14479.14 - 152.36, you got something like 14326.779999999999.
The number of people on forums who completely missed the point and lectured me, often rather condescendingly, on how neither 14479.14 nor 152.36 are exactly representable in finite binary floating point and so that is why the subtraction was not exact was astonishing.
The bug is not that the subtraction is inexact. The bug is that the same subtraction result was displayed with different rounding depending on whether it was done immediately after a clear or done after computing 1143/78.
How 14479.14 - 152.36 displays should only depend on the calculator settings. That it changed depending on previous calculations suggest that there was probably a scratch variable used during calculations that was supposed to be reset before the next calculation but was not.
Speaking of the MacOS calculator, their RPN mode really annoys me (although not as much as Windows 10 calculator which doesn't even have an RPN mode!). Suppose you want to compute (2+3) x 4. The obvious key sequence works: 2 enter 3 + 4 x.
How about (2+3) x pi. The obvious key sequence is: 2 enter 3 + pi x. The result of that is an error beep with pi in the display, or, if you had anything on the stack before you started, that thing multiplied by pi.
That's because rather than pushing pi onto the stack, the pi key replaces whatever is on the bottom of the stack with pi. In other words, instead of acting as if you had hit the keys 3 . 1 4 1 5 9 ... 7 9 3, it acts as if it pops the stack, invokes the function
on the value it popped, and pushes the result.What you have to do is: 2 enter 3 + enter pi x.
Suppose you decide you don't want to have to remember the distinction between the pi key and numerical entry, and decide to just always put in that enter.
So: 2 enter 3 + enter 4 x. That gives you 20 like you would expect...but also leaves a 5 on the stack above that.
For comparison, that does not happen on an HP-15, or on software calculators that follow HP RPN rules, such as pcalc on iOS. On those, when you press enter it duplicates the item currently on the top of the stack, just like Apple's calculator, but it sets a flag that says if you immediately enter a number, that overwrites the top of stack instead of pushing.
This flag was a key thing that made data entry on the HP calculators feel natural.
On the HP-48 they made a significant change to this. When you pressed enter it did not immediately dup the stack and set the flag saying numerical entry should overwrite. Instead, pressing enter did not immediately do anything to the stack. Instead, it set a flag saying that if your next action was to enter a number, first dup the top of stack.
The RPN mode on pcalc lets you select if you want HP-48 stack behavior or classic RPN behavior (it is in advanced settings when you are in RPN mode).
Here's an article on how RPN evolved at HP: http://h20331.www2.hp.com/hpsub/downloads/S07%20HP%20RPN%20E...