Author Topic: TI-Nspire OS 3.6.0.550: Solution depends on display precision?  (Read 4065 times)

0 Members and 1 Guest are viewing this topic.

Offline Goran

  • LV2 Member (Next: 40)
  • **
  • Posts: 32
  • Rating: +0/-0
    • View Profile
Hello,

I came across the following strange behaviour both at CX CAS handheld and in CAS Teacher Software (v3.6.0.550):

I wrote a function that, based on input data, builds a linear system of equations and gives its solution at its output.

I ran it three times (the input data is the same in all the three runs), each times changing Display Digits in Document Settings only.
The systems to solve and the obtained solutions are visible in the attached figures.

In case of "Float 8" and "Float 4" I get the correct solution (although displayed in different precision), in case of "Float 6" not.

When I say "not" I mean the following:

The source of the problem is a difference in matrix coefficients (7,6) and (6,7): the mathematically correct magnitude of both coefficients should be 2.4E-6 (see P.S.), what I get in case of "Float 4" (2.4E-6) and "Float 8" (0.0000024) runs (therefore the correct solution x(1)=x(4)=1.2)

In "Float 6" case the magnitudes are represented as 0.000002, but the problem is that this value not just the representation of number 0.0000024 in "Float 6" precision, the math engine seems work with exactly 0.000002 instead of 0.0000024 (like it truncated the value) and solves a different system corectly, giving actually the "wrong" solution x(1)=x(4)=1.

Seems very strange to me. Or maybe I misunderstand something regarding math engine precision vs numbers representation?

Regards,
Goran

P.S.

The function can solve the system symbolically, too: when symbolic values are supplied, the corresponding coefficients' value is k*sqrt(L1*L2)*omega*imaginary_unit; substituting the numerical values for the described cases  one gets -0.4*sqrt(1E-6*9E-6)*2*imaginary_unit =
= -2.4E-6*imaginary_unit = (2.4E-6 @< -90 deg) in polar notation, what you get in "Float 4" and "Float 8" cases.
« Last Edit: April 03, 2016, 07:28:56 pm by Goran »

Offline Goran

  • LV2 Member (Next: 40)
  • **
  • Posts: 32
  • Rating: +0/-0
    • View Profile
Re: TI-Nspire OS 3.6.0.550: Solution depends on display precision?
« Reply #1 on: March 30, 2016, 07:31:24 pm »
Sorry people, my bad...

I forgot I used a low-level function that actually performed truncation for certain combination of numerical value and the display precision that function string() use.

Simplified to the bones:
"Float4": expr(string(2.4E-6)) = 2.4E-6
"Float6": expr(string(2.4E-6)) = 0.000002
"Float8": expr(string(2.4E-6)) = 0.0000024

The used low-level function must resolve not just numerical values at input, but also symbolic variables + units, therefore I started to play with expr(), string() and # functions, overseeing the cases like above. Fixed it already.

Anyway, no excuse for the post, sorry for your time once more,

Goran


Offline SpiroH

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 729
  • Rating: +153/-23
    • View Profile
Re: TI-Nspire OS 3.6.0.550: Solution depends on display precision?
« Reply #2 on: March 30, 2016, 07:44:07 pm »
Sorry people, my bad...
...
Anyway, no excuse for the post, sorry for your time once more,
No problem, you are welcome.

I'm glad that you fixed it by yourself. Actually, I just tried you example on OS4.2.0.532 and I was getting a slightly different solution.
Well, nvm, it only happens when you dare to do things  ;).

Offline Goran

  • LV2 Member (Next: 40)
  • **
  • Posts: 32
  • Rating: +0/-0
    • View Profile
Re: TI-Nspire OS 3.6.0.550: Solution depends on display precision?
« Reply #3 on: March 31, 2016, 02:27:06 am »
SpiroH,

thanks for understanding, I was kind of desperate after two days searching for the bug... :banghead:

I am curious how slightly and why does your solution differ (do we speak of the system solution or the expr(string(...)) outputs? )

Here arises another, for me very important question:

I am now at v3.6.0.550 for a long, long time and I am cautious to upgrade to 3.9, 4.0 or 4.2 before I am assured by some bugfix changelog document from TI or by the community experience known bugs (if any, of course) are resolved. The caution comes from the fact it seems practically impossible to downgrade later in case of possibly problematic upgrades, while waiting for the next version (here we have a saying something like "Better a  :devil: you know than an  :angel: you don't know" :))

So, from your experience and up to your knowledge, speaking of handheld/software math engine and lua scripting only (I do not use ndless), is it safe to jump to v4.2.0.532?