Leaderboard

Greetings, You are invited to register to participate in the LabVIEW 2015 Platform Beta Program. You can register by visiting http://www.ni.com/beta and selecting "LabVIEW 2015" from the list of beta programs. Please be sure and enter your complete address information in Western characters. All customers outside the United States will have to pass Export Compliance as defined here. Please complete the profile questions to help us understand your experience and use cases with LabVIEW. This information can be critical in whether we accept you into the Beta program or not so more information is better. Make sure you agree to the Terms and Conditions (T&C) of the beta program so that you can complete your registration. After you register, please be patient while the beta coordinator processes your application. You will be notified if you have been approved. Registration does not necessarily guarantee you a position in the beta program. Determination of acceptance into the program is up to the sole discretion of National Instruments. We will have a private section of the Discussion Forums set up for beta users to discuss the beta version of the LabVIEW 2015 Platform. All questions or comments regarding a LabVIEW product that is in beta must be discussed in this private forum. Thank you for your interest in helping us test LabVIEW. Lisa Ely LabVIEW Beta Coordinator National Instruments

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.

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.]

Ohh, man. Now I know again why I didn't use the DOM Parser. This is insane and goes against all and every LabVIEW convention about destroying refnums. But there are other things in that API that make proper resource handling difficult to do.

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

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.

Indeed. I realized that only afterwards. leftover of my other attempts with other types, while trying to understand. Agreed. 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!

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.

Lisa, welcome to LAVA! +1 for posting the announcement here. To all who have never joined the LabVIEW Beta -- this private forum Lisa mentions used for Beta discussion is an excellent resource for the latest in-depth LabVIEW topics. LabVIEW R&D historically has been active and responsive on this forum, and it's your opportunity to influence the product while there's still a little churn remaining before release.

I can do without extra event structures as long as we get an event structure that we can wire TCPIP,UDP, Bluetooth and VISA refnums to.