HP35s Revisited Bug # 14

02212015, 07:17 AM
(This post was last modified: 02212015 07:46 AM by MarkHaysHarris777.)
Post: #1




HP35s Revisited Bug # 14
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 randomsnakebitingyourarsinthegrass 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*QR) ;Should evaluate to roughly 467, and it does R*X/(X*QR) ;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*QR) ;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 Kind regards, marcus 

02212015, 08:45 AM
Post: #2




RE: HP35s Revisited Bug # 14
Even if incorrect, the wrong result is deterministic. Do you know what wrong calculation is done to produce this result?


02212015, 08:59 AM
Post: #3




RE: HP35s Revisited Bug # 14  
02212015, 10:21 AM
Post: #4




RE: HP35s Revisited Bug # 14
(02212015 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:


02212015, 11:24 AM
(This post was last modified: 02212015 12:09 PM by Tugdual.)
Post: #5




RE: HP35s Revisited Bug # 14
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. 

02212015, 06:05 PM
Post: #6




RE: HP35s Revisited Bug # 14
(02212015 10:21 AM)Thomas Ritschel Wrote:(02212015 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. 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 Kind regards, marcus 

02212015, 06:08 PM
Post: #7




RE: HP35s Revisited Bug # 14
(02212015 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 savingrestoring 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 Kind regards, marcus 

02212015, 07:14 PM
(This post was last modified: 02212015 08:00 PM by Thomas Ritschel.)
Post: #8




RE: HP35s Revisited Bug # 14
(02212015 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:
The second equation yields 1.426E3 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, Edit: The different result was due to a wrong formula... 

02212015, 07:51 PM
(This post was last modified: 02212015 08:01 PM by Tugdual.)
Post: #9




RE: HP35s Revisited Bug # 14
Ok, I've got it.
31.32309 = R*X/(466.92696*QR) So basically, the 35s is picking the last result instead of the second "RCL X" and we can assume that "R*X/(X*QR)" 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 Another fun test. Enter the EQN: Code: R*156.25/(X*1.77951304201208.333333334) 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. 

02212015, 08:28 PM
(This post was last modified: 02212015 08:28 PM by Thomas Ritschel.)
Post: #10




RE: HP35s Revisited Bug # 14
(02212015 07:51 PM)Tugdual Wrote: Ok, I've got it. Good job, Tugdual! :) This also explains the other results, e.g.: 0.44491 = R*X/(466.92696*XR) Interesting is also this EQN: Code: (R*156.25)/(Q*X208.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*XR) 

02212015, 09:11 PM
(This post was last modified: 02212015 10:27 PM by Tugdual.)
Post: #11




RE: HP35s Revisited Bug # 14
(02212015 08:28 PM)Thomas Ritschel Wrote: Interesting is also this EQN: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.77951304201208.333333334) => 31.32309 So it looks like any "(RCL X" is replaced by the former EQN result. 

02212015, 10:33 PM
(This post was last modified: 02212015 10:35 PM by Thomas Ritschel.)
Post: #12




RE: HP35s Revisited Bug # 14
(02212015 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.77951304201208.333333334) And then, for example, this as the second equation (using A=1, B=2, C=3): Code: A*2*(B*C1)+B 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*C1)+(B) Quite obviously related to the use of parentheses... 

02222015, 05:41 PM
Post: #13




RE: HP35s Revisited Bug # 14
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.77951304201208.333333334) Then the second equation was one of the following (using A=1, B=2, C=3): Code: A*(B+C) > 5 (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... 

« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)