LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW Object compare doesn't seem to work

Any "good" reason why an object compare (compare aggragate or elements) doesn't work, but if I cast the object to a variant it does?  I am pretty sure this worked in previous versions of LabVIEW (2012) as I had it in my code and it seemed to work then.  I attached the class without methods and type def links to show the data structure.  And why isn't lvclass a supported extension for an attachment?  I just attached it in a zip.

 

I am currently using LabVIEW 2013 SP1 32bit (f2 patch). 

 

ObjectCompare.PNG

0 Kudos
Message 1 of 8
(3,987 Views)

I couldn't open your class correctly (you have mising typedefs in the private data) but once I had removed those three typdef instances, applied changes and did a basic Equals of two class constants the Equals primitive returned true.

 

The Equals primitive is over-riden to do a comparison of the private data cluster, just like normal cluster comparison rules, with a single bool output.

0 Kudos
Message 2 of 8
(3,976 Views)

You can't just use the default class data to do the comparison.  I simplified the class and added a method showing the comparison.  The cluster comparison also fails.  The reason why is an NaN in one of the double variables.  NaN doesn't equal NaN?  I think I remember something about NaN comparisons not working, but they should.

 

TestDataCompare.PNG

Message 3 of 8
(3,958 Views)

No, NaN comparisons don't work. Not because of some flaw in LabVIEW but because they are not supposed to. To understand why, you should dig into the IEEE 754 floating point format to better understand how these formats work. This is an old but extremely wide spread standard describing how floating point numbers are represented by the raw bit data. The long and short of it - there are several floating point representations of the raw bit data that are NaN. So when you compare two values, how should that comparison work? What about the result of operations that return an invalid value for NaN? The IEEE-754 standard helps describe this along with other representations, such as what +/- Infinity mean and how operatiosn are performed on those.

 

With regards to the class constants - I just proved that on my PC the Equals primitive works as expected when provided with two objects that have exactly the same internal data. The problem with your example is that the NaN do not compare as I described above. Thats why there is a NaN? primitive.

 

EDIT:

 

I foiund this link - it was the very first link on my search on google:

 

http://stackoverflow.com/questions/1565164/what-is-the-rationale-for-all-comparisons-returning-false...

 

Also searching for the same terms but including LabVIEW revealed these:

 

http://digital.ni.com/public.nsf/allkb/66AA9498CA1FF5CC8625633A0055AA72

http://labviewwiki.org/NaN

0 Kudos
Message 4 of 8
(3,954 Views)

All the parents private data must be same, check the parent private data fields if in case the class is inherited (child class). Compare function will compare all the private data in the entire class hierarchy and returns true only if entire class trees private data’s are same.

 

Attached sample code for your reference

0 Kudos
Message 5 of 8
(3,944 Views)

Doesn't really help me check if data in my object changed (in a way that doesn't require me to update a custom comparison vi with NaN checks every time I update my class data).  Maybe NI should rethink this.  It is all well and good when comparing a single NaN to another NaN, but not when you have a bunch of doubles in your cluster or class that could contain an NaN.

 

Somehow the variant method works which is nice.  I checked just changing an NaN to a variant and comparing and it works.  Unfortunately these NaN's are being used to feed into a MatLab built DLL to check to use a default value or a non-default value (user entered a valid value, or if NaN use the default value).

0 Kudos
Message 6 of 8
(3,937 Views)

@klessm1 wrote:

Doesn't really help me check if data in my object changed (in a way that doesn't require me to update a custom comparison vi with NaN checks every time I update my class data).  Maybe NI should rethink this.  It is all well and good when comparing a single NaN to another NaN, but not when you have a bunch of doubles in your cluster or class that could contain an NaN.

 

Somehow the variant method works which is nice.  I checked just changing an NaN to a variant and comparing and it works.  Unfortunately these NaN's are being used to feed into a MatLab built DLL to check to use a default value or a non-default value (user entered a valid value, or if NaN use the default value).


The NaN comparison works in the Variant form becuase it's not really performing a floating point comparison of the NaN per se. Still it might be the best solution for now for your Matlab integration.

 

The standard specifies how to handle NaN comparison, and LabVIEW complies with this. Going away from the standard would cause a great deal of confusion since it would now be different then other software environments that do comply (and most do). I for one would not vote for this idea, as counter-intuitve as that seems. Out of interest - have you tried performing the NaN equality in Matlab? I don't have it installed but am curious what the results are.

 

You should really read the link I gave you - one of the founding members of IEEE-754 explains why things are the way they are. Floating point numbers are just a big hack after all.

0 Kudos
Message 7 of 8
(3,928 Views)

I haven't tried the NaN compare in Matlab.  However I would guess they they are following the same rules as they are using the "isnan" function in the program I am interfacing to: "if(~isnan(win_id))".

 

What I will probably end up doing is creating a generic object compare function using the LabVIEW base class and make it "object data changed" instead of an equality\inequality comparison.  This would implement the to variant and perform the comparison.  If someone wants to use the "technically correct" method they can always use the normal equals.  However I don't see much use in this method for a value changed check as you are looking at the same object.

 

For a "is class a the same as class b" comparison then you would want to use the normal equals though because you don't know where the data for each was produced (e.g. calculated data resulting in NaN for two objects would necessarly be "equal").    

0 Kudos
Message 8 of 8
(3,885 Views)