bug in comparison of class objects? Or in shift register?

[ensegre]

I ran into this. Two class objects which should be identical, result as different in the following:

I've tried a few variations of the snippet, and it seems that the comparison of this particular class object with its data (but not other instances) diffs if the shift register is involved, while two static copies of it would result as identical.

Intriguingly, if I pass the objects to the subVI Diff... they result as identical.

 

Is someone able to shed light? I'm on LV2014/linux, haven't yet tried in other versions.

ClassComparisonBug.zip

Edited January 28, 2015 by ensegre

[ensegre]

Ok, I understood something: my object has some NaNs, so I'm essentially affected by (NaN != NaN) being true.

However, there is still something which puzzles me: to test the differences between passing the data reference in a tunnel or a shift register I've put together this variation

The class object and the cluster (or even a single NaN constant, for what matters) don't behave the same way

I could speculate that the Equal? and the Not Equal? blocks are smart in some way that avoids the detailed comparison if they know a priori that the data reference is the same, and that the shift register must do a data copy at every iteration; however, something may be different in the mechanics for classes. Intriguing.

[Aristos Queue]

Ignore previous post. I found your bug. Please hold while I type it up.

[Aristos Queue]

So... there is a bug in LabVIEW. It has to do with NaN.

 

When there are two objects in memory, LabVIEW compares them, just like it does any other type. But there's a small performance cheat -- if the two objects are from the same memory address, the function returns TRUE -- they are equal. But that's not true if the class could contain a NaN. So we need to eliminate the performance check. This is why your comparison against the tunnel value directly gave different results than the other two comparisons.

 

What threw me off was some of your comments about how these should be equal and the subVI wasn't giving the same results as the caller. Here's a couple tidbits that might help your understanding of the issue.

 

a) NaN compares false when compared against itself and true for not equal.

b) SubVI isn't going to show its results because you've got it marked as inline. The VI that you're looking at never executes so the panel never updates. That accounts for the difference between the caller and the subVI. Turn off inlining and you'll see the panel update.

c) Compare Agg vs Compare Elt does not affect classes. Classes are defined as scalar values. Their internal implementation is opaque to external callers of the class. A class containing NaN compared against itself will always say it is not equal (so the Not Equal prim will return true). [barring the bug mentioned above.]

[Aristos Queue]

For the record, this bug goes all the way back to 2003 (before LV classes were even released to the public in 2005 beta or 2006 release). It has not been reported before now. It affects a corner case -- you have to have a class that contains floating point fields, whose value is NaN, which is compared against itself. I recognize that comparing a value against itself is exactly how you detect NaN, but that is only going to apply to classes that are, in aggregate, being used to represent numeric calculations, so I'm not surprised the bug has gone this long without being noticed.

 

I'll make sure it gets addressed in LV 2015. It is too late for 2014 SP1.

Edited January 28, 2015 by Aristos Queue

[ensegre]

b) SubVI isn't going to show its results because you've got it marked as inline. The VI that you're looking at never executes so the panel never updates. That accounts for the difference between the caller and the subVI. Turn off inlining and you'll see the panel update.

Indeed. I realized that only afterwards.

 

c) Compare Agg vs Compare Elt does not affect classes. Classes are defined as scalar values.

 

leftover of my other attempts with other types, while trying to understand. Agreed.

 

For the record, this bug goes all the way back to 2003 (before LV classes were even released to the public in 2005 beta or 2006 release). It has not been reported before now. It affects a corner case -- you have to have a class that contains floating point fields, whose value is NaN, which is compared against itself. I recognize that comparing a value against itself is exactly how you detect NaN, but that is only going to apply to classes that are, in aggregate, being used to represent numeric calculations, so I'm not surprised the bug has gone this long without being noticed.

my aim was to detect value changes in the class object, hence I'll have to decide whether I still want to allow NaNs as data in it and go like this, or to change design.

 

Thanks for your investigation and for escalating the matter for me!

[Aristos Queue]

Update: I may not be changing this in 2015. This change turns out to have ramifications on various other aspects of classes, and there's a significant discussion about which way is the right way to fix it. When aggregated inside of a collection, handling NaN as NaN makes sense. But when aggregated as part of an object, it seems to make much more sense to treat NaN as data -- i.e. NaN == NaN -> TRUE. Having it return FALSE betrays the abstraction of the private data -- just because I use a double as my internal data and happen to use NaN as a sentinel should not change the external view of the object as a single coherent whole.

 

Personally, I'm strongly persuaded by this argument and I'm doing further investigation into how other languages resolve this.