My analysis of Joel's HP35s' bug Message #1 Posted by Valentin Albillo on 16 Oct 2007, 9:37 a.m.
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 noninterruptable 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*QR) = 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/(43*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/(4SQRT(19/6)/(1/3SQRT(19/6)/4))
which can be recognized at once as the result of evaluating:
R*X/(REGX*QR)
where REGX is of course the result of previously evaluating:
R*X/(X*QR)
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.
