Bug with corrupted controls that have units

[Jason H]

I found a nasty bug where a control that has units associated with it somehow appears to get corrupted. When a corrupted control and a normal control are fed into the equals function, it returns false. It's not limited to controls either, a corrupted and normal constant will return as not being equal.

Example vis are attached.

labview bug with units example original.vi

labview bug with units simple example.vi

[drjdpowell]

I found a nasty bug where a control that has units associated with it somehow appears to get corrupted. When a corrupted control and a normal control are fed into the equals function, it returns false. It's not limited to controls either, a corrupted and normal constant will return as not being equal. Example vis are attached.

I don't have LabVIEW 2011 and can't open the VI's; but, could this be an issue with floating point numbers and the "equals" operation? One should never do "equals" with floating point, because the two numbers from different calculations can be tiny bit different even if the calculations should mathematically be identical.

-- James

[asbo]

If I'm not mistaken, a non-unit'd value wired against a unit'd value should break the wire. I don't have LV2011 installed either, so I can't take a look at those VIs.

[drjdpowell]

Just got LabVIEW 2011, and it is because of small differences in value of the floating point numbers. Increase the display format to 19 significant figures and you'll see you are actually asking in 1 mm is equal to 1.000000000000000890 mm. The correct answer is "no". In general, one should never use the "equals" operation with floating point numbers, because an insignificant (to us) difference is still a difference to the computer. Instead, one should subtract the two numbers, take the absolute value of the difference, and see if that is less than some small "tolerance" number.

Edited September 13, 2011 by drjdpowell