LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Rounding error causes strange behavior in comparisons

Solved!
Go to solution

Hi all,

 

I found a rounding error in my code yesterday, which seemingly causes something impossible to happen. A comparison of one number to another in a greater than is true, and the same comparison in a less than or equal to is also true. I've attached a zip folder with a test VI and the values that produced the problem, in the README file. You only need to set Xa,Xb,INSfp,DEXfp,Weight,DEXcon,and 5min b/t Xa and Xb. None of the other controls on VariableCluster matter, as you'll see when you open up rule015 and rule016.

0 Kudos
Message 1 of 6
(2,882 Views)
Solution
Accepted by topic author ijustlovemath

Alright, so this is a rounding issue, but it is avoidable.

 

First, some backround. Floating point arithmetic itself has rounding issues that are very well known and are an accepted issue. Here is a resource for more info.

 

Your specific problem is occuring because you didn't do your calculation operations in the same order for each comparison. You have (Wt*6*DEXcon_inv) in rule015, but (DEXcon_inv*Wt*6) in rule016. Match those calculation orders to each other and see what happens.

 

Edit: For future reference, you should use subVIs for calculations like that. This will standardize the calculation itself so you don't run in to problems like this and it will also make it easier to make alterations to your calculations in the future.

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


Message 2 of 6
(2,871 Views)

It's fixed! Wow. Fortunately, I have some error handling that notifies me when this happens, but the code I'm working with is legacy. There's over 300 of these rules, and god knows what the other programmer was doing when they built them out. Thanks for the article, I'll be sure to read up on more floating point stuff!

0 Kudos
Message 3 of 6
(2,859 Views)

James.Morris wrote:

Your specific problem is occuring because you didn't do your calculation operations in the same order for each comparison.


Even doing the computations in the same order can lead to different results at different times, (typically very rarely, e.g.  if there is a context switch that saves the 80bit internal CPU registers as 64bit (example)).

 

It can occur in LabVIEW and I have run into this situation. An illustrative example is described here.

Message 4 of 6
(2,830 Views)

Well gosh darn it. Zeroes and ones need to learn their place.

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 5 of 6
(2,817 Views)

@ijustlovemath wrote:

It's fixed! Wow. Fortunately, I have some error handling that notifies me when this happens, but the code I'm working with is legacy. There's over 300 of these rules, and god knows what the other programmer was doing when they built them out. Thanks for the article, I'll be sure to read up on more floating point stuff!


Thanks are best given in the form of Kudos (Unofficial Forum Rules and Guidelines). You received help from some top-tier LabVIEW experts here (and one of your other threads), whom I'm sure would appreciate your gratitude.

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 6 of 6
(2,788 Views)