HP35s Revisited Bug # 14

[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...