Threaded Mode | Linear Mode

Marcio · (This post was last modified: 06-26-2015 07:06 PM by 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.