HP35s Revisited Bug # 14

[MarkHaysHarris777]

Of the firmware bugs listed for the HP35s, number(s) (14), (15), (19), & (20) are the real buggers and of those only bug (15), the one I call 'The Royal Gotcha', is the only 'real' bug (and its a doozy); however, its not a random-snake-biting-your-ars-in-the-grass kinda thing... its a matter of cause and effect--- if you know what causes the bug, you may avoid it completely (and you better!)

I will address each of these bugs in turn, beginning in this article with number (14), the abstract of which might read, “EQN incorrectly evaluates certain expressions”. From the bug list:

14. (program)
LBL A
156.25
STO X
208.333333334 ;There are eight 'threes' in there
STO R
1.77951304201
STO Q
-R*X/(X*Q-R) ;Should evaluate to roughly -467, and it does
-R*X/(X*Q-R) ;Should (still) evaluate to roughly -467, but
calculator outputs 31.323 instead!
RTN

While I can affirm the above scenario, it is first important to note that the observed 'error' has nothing to do with the calculator proper, nor with programming. This scenario may be reproduced manually; however, the scenario is not quite correct, and there is a work around. This occurs for the combined reasons that some numbers cannot be held in memory accurately (therefore some intermediate results are going to be tricky) and the EQN mechanism being employed cannot be 'reset' or cleared (be aware of this) we'll discuss it later. Secondly, if you change this scenario even a little the observed 'error' goes away. For R: modifying R slightly removes the observed 'bug'.

To see what's going on I suggest reworking the program a bit so that we can repeat the EQN evaluation over and over... to see what the effect might be. Try this:

14. (program)
LBL A
156.25
STO X
208.333333334 ;There are eight 'threes' in there
STO R
1.77951304201
STO Q
LBL B
-R*X/(X*Q-R) ;Should evaluate to roughly -467, but toggles ever other R/S
(calculator outputs 31.323 instead!)
STOP
GTO B001
RTN

Run this program and notice something VERY interesting... evey other evaluation will be correct!

Every other time R/S is pressed the evaluation will be correct, and alternate times will be incorrect.

What is happening here?

The answer: The EQN mechanism may be thought of as a calculator within a calculator (from Princess Bride, “A dweam, wiffin a dweam...”) The binary combination of certain real numbers, and the fact that the EQN system is not being reset, causes every other display to be incorrect. The 'incorrect' display is actually (in a bizarre way) causing the EQN system to be reset, so that every other evaluation is displayed correctly. Add these lines after LBL B and the problem will go away:

CLx
0
√x

Performing the unary function √x on zero resets the EQN system so that every evaluation now performs correctly. There are other unary functions that have the same effect, for instance 1/x.

Now, please, remove those three lines for the next piece of the demo and change the program to look exactly like this:


14. (program)
LBL A
156.25
STO X
208.333333334 ;There are eight 'threes' in there
STO R
1.77951304201
STO Q
LBL B
-R*X/((X*Q)-R) ;Should evaluate to roughly -467, but toggles ever other R/S
(calculator outputs 31.323 instead!)
STOP
GTO B001
RTN

Do you see the subtle change? Look closely at the equation...

If we force the EQN system to stack another nested () then the binary representation of reals in the intermediate results change and the problem goes away... try it.

The above program will evaluate the expression -R*X/((X*Q)-R) correctly over and over.

Conclusion: The EQN system is a calculator within a calculator (infix calculator, with AOS no less) which needs to be reset between runs (manual as well as programmed). Performing a unary function √x on zero resets the EQN system internally. Can the EQN system be relied upon? Yes. But the user is ultimately responsible to test the EQN method, the domain and range of the problem, and the expected results (one never simply 'trusts' their calculator!). The user may reset the EQN system in the way described. The user may also chose to NOT use the EQN system and simply program the equation or expression directly... my personal choice.

The EQN system is an AOS infix calculator within a calculator (which for our purposes is probably configured as RPN). Give that some thought for a minute. 1) it doesn't make sense, and 2) the methodology should 'grate' on everyone's last nerve. Relying on an infix methodology 'under the covers' where intermediate results cannot be checked, and where the AOS may or may not be working correctly, nor whether the AOS is properly reset to begin with, is insane. The user has a fully featured programmable calculator at their fingertips (they should program the beast!) and leave the EQN system to TI and CASIO. Just because you have a button labeled EQN does not mean you HAVE to push it. Like Daffy Duck says, "Never pushshh the purple button!"

Having said that, feel confident to use the EQN system, but don't trust it. Check it, test it, verify it, and have a good working knowledge of your domain and range. The EQN system of the HP35s is actually very sophisticated and highly useful. It does have caveats, and ultimately the user is in control and has the responsibility. On the other hand, the HP35s can be used time on end without ever resorting to the internal EQN system!

Cheers,
marcus