My analysis of Joel's HP35s' bug

[Valentin Albillo]

Hi, all:

I'm starting this new thread instead of directly replying to the original message by Meenzer because it was getting very deeply nested and besides it was somewhat ancillary re the first posting on that thread which was about neverending, supposedly non-interruptable loops and such.

Here I'll briefly comment on my analysis of Joel's bug, as described in Meenzer's message. In order to get an idea of just what's happening and why we aren't getting the expected correct result it's fairly obvious that to be able to make any progress at all it is essential that we get to know exactly what are we getting instead. That is, we must identify that weird 31.323 resting defiantly on our screen.

A little fiddling with my own program IDENTIFP, described in my Datafile article "Boldly Going ... - Identifying Constants" (which you can download in PDF format for free at my Calculators web site) quickly reveals the following when applied to all inputs and outputs:

      X = 156.25,        gets identified as 5^4/4 

      R = 208.333333334, gets identified as 5^4/3

      Q = 1.77951304201, gets identified as SQRT(19/6)

      -R*X/(X*Q-R) = -466.926956302, 

          this actually doesn't need any identification, since we know exactly 

          how it is computed and have already identified the inputs.

          Anyway, for the sake of completeness it gets identified as

                   5^4/(4-3*SQRT(19/6)) 

Now, the mystery value, which in full is 31.3230923085, after some playing around with IDENTIFP gets identified as:


        31.3230923085 = 5^4/(4-SQRT(19/6)/(1/3-SQRT(19/6)/4))

which can be recognized at once as the result of evaluating:


       -R*X/(REGX*Q-R)  

where REGX is of course the result of previously evaluating:


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

so, essentially, the bug consists in that some internal coding error in the HP35s ROM is replacing the second reference to direct variable X in the second equation with a reference to stack register X instead.

What the internal coding error consists of is anyone's guess.

Best regards from V.

[Meenzer]

Thank you for opening a new thread and analyzing so beautifully the problem. Just as an aside I wanted to note that the wrong result comes up no matter what variable name you put in the EQN. So, if you replace X with K, it's still buggy. It seems at least there is no direct relation between the variable X and REGX.


I now did the following, just for fun I entered "-S*L/(K*R-S)" as an EQN, providing it with the same numbers for L and K as they both stand in for X.
Result: first time I get asked all 4 variables and obtain the correct result. Second time I get no prompt for K and the result is wrong. Third time is like first time, fourth time like second and so on...

When I now key in "-S*L/(K*R-T)", providing S and T with the original R value, the 35s still asks me for S and T in every run but omits asking for K every second time, with the same alternating results as above.

Edited: 16 Oct 2007, 10:18 a.m.

[Valentin Albillo]

Hi, Meenzer:

Meenzer posted:

"So, if you replace X with K, it's still buggy. It seems at least there is no direct relation between the variable X and REGX."

Yes, I knew, Meenzer. I don't actually state in my analysis above that the different X are related, matter of fact someone in the previous thread already mentioned that a change of variables makes no difference. Both being named X is most probably a coincidence.

After a pretty enthusiastic start, I'm beginning to worry somewhat about the HP35s (yet Gene said that this particular trait is also to be found in the HP33S, though no one knew).

Best regards from V.

[Meenzer]

I now keyed in the EQN as "-R*X*INV(X*Q-R)" which should be mathematically identical, both in EQN mode and as an EQN in a program. Both times the results are allways correct.

When I change the original EQN to "-R*X/((X*Q-R))" with two pairs of parentheses, the result is also correct, both in EQN mode and in a program. So maybe it's a problem of operator priority.

Valentin, I know you didn't state that X and REGX had something to do with one another. I just wrote that to clarify, partly for myself ;-)

Edited: 16 Oct 2007, 5:26 p.m.

[Karl Schneider]

Hi, Valentin --

That looks like great work! I'll have to check out your "IDENTIFP" promptly, because I don't understand the concept of identifying constants as something other than exactly the entered value. (Perhaps "gets identifed" really means "can be identified"?)

At the 2007 San Diego HHC conference, Cyrille showed how some of the bugs in the HP-33s were likely introduced. I'm sure that there are other gremlins waiting to trip us up.

-- KS

Edited: 16 Oct 2007, 5:28 p.m.

[Valentin Albillo]

Hi, Karl:

Karl posted:

"That looks like great work!"

Thanks for your kind appreciation

"I'll have to check out your "IDENTIFP" promptly, because I don't understand the concept of identifying constants as
something other than exactly the entered value."

Please do. I think that a mathematically inclined reader such as you will probably find it very interesting, a real eye-opener. Essentially a very simple concept, yet the math applications seem limitless. You see, it can even be used for "forensic" detection purposes ! :-)

"Perhaps "gets identifed" really means "can be identified"?"

You could say so, if you wish. IDENTIFP outputs both the symbolic expression that most closely evaluates to the constant being identified (depending on some input parameters such as range of functions to try, tolerances, etc) and a confidence indicator which goes from 0% to 100% and essentially measures the identification's reliability.

Values 95% and above are labeled "identified as" while lesser values are labeled "might be" and then it's up to the user to decide whether the alleged symbolic identification holds math merit or not. Please see the many (and I mean many) carefully chosen examples in the article to see how it all fits.

"At the 2007 San Diego HHC conference, Cyrille showed how some of the bugs in the HP-33s were likely introduced."

Should that be outside the NDA, it would be very interesting to get to know, to further heighten our understanding of the many caveats and pitfalls awaiting the daring ROM coders.

Best regards from V.