08-25-2015 11:02 AM
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.
Solved! Go to Solution.
08-25-2015 11:16 AM - edited 08-25-2015 11:22 AM
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> ---'
08-25-2015 11:21 AM
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!
08-25-2015 12:27 PM
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.
08-25-2015 12:34 PM
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> ---'
08-25-2015 04:17 PM
@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> ---'