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

[Tugdual]

Even if incorrect, the wrong result is deterministic. Do you know what wrong calculation is done to produce this result?

[Thomas Klemm]

TL;DR

(02-21-2015 07:17 AM)MarkHaysHarris777 Wrote:  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.

[Thomas Ritschel]

(02-21-2015 07:17 AM)MarkHaysHarris777 Wrote:  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.

Apart from your example I tried the following variants of the same equation. While some of them are working, I was able to generate a bunch of other bad results:

Code:


 equation          second result
--------------------------------------
 R*X/(R-X*Q)      -466.926...  correct
-R/(Q-R/X)        -466.926...  correct
 R/(R/X-Q)        -466.926...  correct

-X*R/(X*Q-R)        31.323...  wrong
-X*R/(Q*X-R)         0.444...  wrong
-R*X/(Q*X-R)         0.444...  wrong
-(R*X)/(X*Q-R)     -70.202...  wrong
-(X*R)/(X*Q-R)      93.603...  wrong
-(R*X)/(Q*X-R)      -0.997...  wrong
-(X*R)/(Q*X-R)      -1.329...  wrong

[Tugdual]

Other interesting fact is that is you enter values instead of using variables, the result is always correct. Is that related to the way we pull variables or does it somehow affect the syntax?

I also tried to change the variables, using A,B,C instead of Q, R, X, just in case there could be a possible misinterpretation but nada.

[MarkHaysHarris777]

(02-21-2015 10:21 AM)Thomas Ritschel Wrote:  

(02-21-2015 07:17 AM)MarkHaysHarris777 Wrote:  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.

Apart from your example I tried the following variants of the same equation. While some of them are working, I was able to generate a bunch of other bad results:

Yes, I went down that path as well. The real problem (for this example) is the value of R (and as Tugdual points out) also the use of variables. The EQN system has some issues, and as we'll see in bug # 15 (coming later) some of that can cause data loss if you're not aware.

Cheers,
marcus

[MarkHaysHarris777]

(02-21-2015 08:45 AM)Tugdual Wrote:  Even if incorrect, the wrong result is deterministic. Do you know what wrong calculation is done to produce this result?

Let me know if you figure it out. I thought it might have to do with the idea that EQN may be using the same memory (variables) without properly saving|restoring the environment. (don't know yet) Clearly, running the EQN system once leaves the system in a state or environment that interferes with the next run... still playing with it/

marcus

[Thomas Ritschel]

(02-21-2015 06:08 PM)MarkHaysHarris777 Wrote:  Clearly, running the EQN system once leaves the system in a state or environment that interferes with the next run...

Here is another variant using two equations with different sets of data:

Code:


A001 LBL A
A002 1
A003 STO A
A004 2
A005 STO B
A006 3
A007 STO C
A008 156.25
A009 STO X
A010 208.333333334
A011 STO R
A012 1.77951304201
A013 STO Q
A014 -R*X/(X*Q-R)
A015 -A*B/(B*C-A)
A016 RTN

The second equation yields 1.426E-3 while it should be -0.4.
The problem disappears if a simpler second equation is used (e.g. just A+B*C).

BTW.: The HP 33s has the same bug, but the results are different.

Edit: The different result was due to a wrong formula...

[Tugdual]

Ok, I've got it.

31.32309 = -R*X/(-466.92696*Q-R)

So basically, the 35s is picking the last result instead of the second "RCL X" and we can assume that "-R*X/(X*Q-R)" is evaluated with the equivalent RPN (very flat RPN but the I believe it is by design to avoid the use of a stack):

Code:

RCL X
RCL Q
*
RCL R
-
1/x
RCL R
*
RCL X
*
CHS

Another fun test.
Enter the EQN:

Code:

-R*156.25/(X*1.77951304201-208.333333334)

First attempt, the 35s asks for R?, then X? and returns -466.92696
Now pay attention, execute the EQN a second time. The 35s will ask for R?... skip X? and returns 31.32309.

Extremely odd bug because it also depends on values. With X=156.1 there is no problem... I wonder if the calculator somehow forgets to acknowledge that the former calculation was completed. May be there is a carry over or a precision issue and it leaves the calculation in an incomplete state and the next one restarts from its last value.

[Thomas Ritschel]

(02-21-2015 07:51 PM)Tugdual Wrote:  Ok, I've got it.

31.32309 = -R*X/(-466.92696*Q-R)

Good job, Tugdual! :-)

This also explains the other results, e.g.:
0.44491 = -R*X/(-466.92696*X-R)

Interesting is also this EQN:

Code:

-(R*156.25)/(Q*X-208.333333334)

In the first run it asks for all three variables, but in the second run it only asks for X and then returns -0.99715.

So, obviously here it uses the old result -466.92696 for both variables, R and Q:
-0.99715 = -(-466.92696*X)/(-466.92696*X-R)

[Tugdual]

(02-21-2015 08:28 PM)Thomas Ritschel Wrote:  Interesting is also this EQN:

Code:

-(R*156.25)/(Q*X-208.333333334)

In the first run it asks for all three variables, but in the second run it only asks for X and then returns -0.99715.

So, obviously here it uses the old result -466.92696 for both variables, R and Q:
-0.99715 = -(-466.92696*X)/(-466.92696*X-R)

Hmm would it be related to opening parenthesis?

Edit: obviously yes!
I took my former EQN and added parenthesis at the beginning

Code:

-R*156.25/(X*1.77951304201-208.333333334) => 31.32309
became 
-(R*156.25)/(X*1.77951304201-208.333333334) => -70.20286

Now R is also totally skipped, meaning that the second time XEQ EQN doesn't prompt for any value and returns -70.20286.

So it looks like any "(RCL X" is replaced by the former EQN result.

[Thomas Ritschel]

(02-21-2015 09:11 PM)Tugdual Wrote:  Hmm would it be related to opening parenthesis?

Seems to be.

I played with using different equations for the second step.
First EQN is yours:

Code:

-R*156.25/(X*1.77951304201-208.333333334)

And then, for example, this as the second equation (using A=1, B=2, C=3):

Code:

-A*2*(B*C-1)+B

It will ask for A, C, and B (in this order), but yields 2805.5617 instead of -8.

If this second equation is run alone, then it asks for A, B, and C (in this order) and correctly returns -8.
Obviously the equations are evaluated from left to right.

Let's change the second equation into this one:

Code:

-A*2*(B*C-1)+(B)

Now it only asks for A and C and yields 2336.6348 (wrong again).

Quite obviously related to the use of parentheses...

[Thomas Ritschel]

I did some more experiments using different equations in order to determine the conditions for yielding bad results in the second step.

The first equation (necessary to trigger the "bad" state of the EQN system) is as before:

Code:

-R*156.25/(X*1.77951304201-208.333333334)

Then the second equation was one of the following (using A=1, B=2, C=3):

Code:

 A*(B+C)   ->     5        (correct)
-A*(B+C)   ->   463.92695  (wrong)
-A*(B)     ->   466.92695  (wrong)
-(A)*(B)   ->  -218020.78  (wrong)
 (A)*(B)   ->     2        (correct)
-A*B       ->    -2        (correct)
-A         ->    -1        (correct)
-(A)       ->   466.92695  (wrong)
-(-A)      ->     1        (correct)
 (-A)      ->    -1        (correct)
-((A))     ->    -1        (correct)
(-(A))     ->   466.92695  (wrong)
-(-(A))    ->  -466.92695  (wrong)
((-(A)))   ->  -466.92695  (wrong)
(-((A)))   ->    -1        (correct)

We can spot two necessary conditions for the bad results:
(1) The equation must start with a CHS (-).
(2) There must be an opening parenthesis immediately followed by a variable name.

As Markus already pointed out, one solution seems to be the use of additional (double) parentheses around the variables. For example, by changing -(A) into -((A)) or better -A, but not (-(A)) or ((-(A))).
However, for more complex equations this might be a mess...