LabVIEW
Comparison of Collections
Today I was writing some tests for an object that stores a registration (using the Registration Map malleable VIs, essentially wrapping a Map collection) and I discovered that comparing collections behaves differently than I would have expected.
This example snippet uses Sets to simplify the demonstration, but the same is true with Maps.
Note that comparing the collection to itself (same wire) returns True, but comparing to a collection with the same contents is False.
Is this expected behaviour? If so, could the help for Equals? be improved to reference this (in a similar fashion to the information about VI Server references)?
Comparing sets and maps for equality doesn't seem such a strange thing to do for this to not be a supported behaviour.
Search LabVIEW like a graph! At some point I decided setting the Code Capture Tool to 2015 would be most useful.
Unfortunately, apparently that functionality not only doesn't work as intended, it makes clearly false claims that it does work when clearly it couldn't (like Sets in 2015...)
Having had at least the first part of that pointed out to me recently, I have tried to change them to just save in 2019 (since that's what it's actually saving, avoiding false promises) but clearly I missed the computer I posted that from... 😕
I'd be interested to know if there is a problem with the compare function, or if there is a difference between a fresh set and an empty set.
Can't use 19 yet, so here are some experiments...
What does the Not Equal? do when the set are equal? And when they're not equal?
What does the Equal? return when comparing the result of the wire from Insert Into Set on both inputs? And what if you copy the insert, and compare the two results?
What does the Equal? return when comparing the result of the wire from Remove From Set on both inputs? And what if you copy the insert and remove, and compare the two results?
Here's the updated set of comparisons.
By a convenient quirk of different computer default values, the new indicators are in NXG style, and so stand out.
I also added the strings in "\" display mode - like RavensFan, this was one thing I considered, since lvclass files with no changes from default are different to lvclass files where everything is set to default (I think - at least, the data is not stored if all values are default - I haven't closely compared setting to default values to assert that they change the binary value).
As can be seen in the results here, adding then removing the same value from two copies of the set does make them compare equal.
Not Equal is as expected for different Sets.
Not Equal is as expected based on my previous findings for the "same-ish" set, that is, a set with some operations that leave it in the empty state, compared with an empty set with no changes.
Edit: as a further check, flattening to XML rather than String gives the following string (same in both cases where previously flattening to string) (again in "\" display style):
<Set>\r\n<Name>Empty\sSet</Name>\r\n<NumElts>0</NumElts>\r\n</Set>\r\n
So it seems there is a difference between a virgin set and a 'used but empty' set?
Once used, everything works as expected (except when comparing it to a virgin set)?
I wander if a "Always Copy" after the constant takes the sets virginity. Maybe even a structure tunnel (put it in a sequence structure)? Of course (though you never know until you try) removing any item from the virgin set will spoil it?
Is there a difference between an empty set constant and an empty set control?
