[HP 35s] Has anyone ever been stung by bug 14?

[Marcio]

Hello all,

As some of you know, BUG 14 makes reference to the solver of the 35s, which seems to have a hard time organizing variables in the memory:

Code:


LBL A
156.25
STO X
208.333333334 ;There are eight 'threes' in there
STO R
1.77951304201
STO Q
-R*X/(X*Q-R) ;Should evaluate to roughly -467, and it does
-R*X/(X*Q-R) ;Should (still) evaluate to roughly -467, but
calculator outputs 31.323 instead!
RTN

(That is scary!)

Some people in the forums call it 'a bad calculator inside a good calculator'. So, my question is Has the solver ever failed any of you?. I mean the solver that is called from the equation library, I suppose they're the same so, I was wondering if I should trust it or not. I am only asking this because I have read so many bad reviews that I kinda feel like I should ask people who are still using the machine for serious work.

Very much appreciated.

Marcio

[Dieter]

(06-26-2015 02:14 PM)Marcio Wrote:  So, my question is Has the solver ever failed any of you?. I mean the solver that is called from the equation library, I suppose they're the same so, I was wondering if I should trust it or not.

Until now the 35s solver has never let me down and returned reliable results.

I also do not think that "bug 14" is related to the solver. The problem may be caused by the equation parser, and maybe the bug even appears only in program mode. I tried the example you posted (equation = –467) and manually solved for X several times. the results were correct and consistent.

Dieter

[Marcio]

Thanks.
And yes.

In this thread, a few forum members apparently identified the source of the problem:

(02-22-2015 05:41 PM)Thomas Ritschel Wrote:  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...

The problem however is that no one knows if the problem will be triggered if the same variables are used latter in a lengthy program.

So I think users will have to agree with this gentleman when he says:

(02-21-2015 07:17 AM)MarkHaysHarris777 Wrote:  ...The user may also chose to NOT use the EQN system and simply program the equation or expression directly... my personal choice.

... leave the EQN system to TI and CASIO. Just because you have a button labeled EQN does not mean you HAVE to push it.