My analysis of Joel's HP35s' bug



#7

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.

#8

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.


#9

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.

#10

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.

#11

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.


#12

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.

Possibly Related Threads...
Thread Author Replies Views Last Post
  HP35s Program Four Slings Lift Calculation Jean-Marc Biram (Australia) 2 1,060 12-16-2013, 07:21 PM
Last Post: Jean-Marc Biram (Australia)
  HP35s Calculator Max Rope Tension Program Jean-Marc Biram (Australia) 10 2,087 12-12-2013, 12:03 AM
Last Post: Jean-Marc Biram (Australia)
  Entering,Saving,and Analysis /Fitting X Y Data on the Prime Harold A Climer 6 1,206 10-26-2013, 01:54 PM
Last Post: Tim Wessman
  HP85 Waveform Analysis inaki 1 544 04-23-2013, 01:20 PM
Last Post: Paul Berger (Canada)
  Trouble entering a HP35s program line Arno 2 741 04-05-2013, 06:28 PM
Last Post: Arno
  HP35s scientific calculator GREG W THOMAS 4 882 03-22-2013, 06:49 AM
Last Post: Thomas Radtke
  HP35s "MEMORY CLEAR" flashes Mark Paris 1 596 08-31-2012, 07:35 PM
Last Post: Bart (UK)
  HP35S keyboard Nick R 8 1,272 08-01-2012, 01:27 PM
Last Post: Dave Shaffer (Arizona)
  Hp-41 structural analysis pac porting to hp49g+ giancarlo 7 1,207 05-14-2012, 04:14 PM
Last Post: Luiz C. Vieira (Brazil)
  Where should I post new HP35s bugs Andres Capdevila 33 3,638 03-13-2012, 01:00 PM
Last Post: Jeff O.

Forum Jump: