Deficiency in Maps

[paul_cardinale]

When you have 2 references to the same object, under the hood, they may have different numeric values, but even so, comparison functions (e.g. ) work as you would want: They check whether the references refer to the same object, not whether they have the same numeric value.  The "Search 1D Array" function () also works like that.

But if you use a reference as a key in a map, the function "Look In Map" (), doesn't work like that, it just checks the numeric value of the key.  (Drat.)

[MichaelBalzer]

That's interesting to know. I assume the two same-but-different reference keys can be inserted into the map at the same time too? (ie. one doesn't replace the other)

The help for the equals function states the reference comparison will return true if the object is the same, and to type cast the reference to a number if you need to compare the reference value itself. Given the equals and search 1D array functions work in this way, I'd say it's a bug that the map VIs treat reference comparisons differently. Given this behavior has presumably been there since maps/sets were added in LV2019, I don't see it being changed now. The least NI can do now is update the maps/sets documentation that reference comparison doesn't check the underlying object.

[LLindenbauer]

That's a remarkable discovery!

I remember stepping into that trap, too. The associative array in python (i.e., a dict()) requires the key to be immutable and hashable (https://stackoverflow.com/questions/2671376/hashable-immutable). I don't know, but have little doubt that LabVIEW has similar requirements. With a reference, the reference itself fulfills the requirement, but the referred object does not: The referred object can change substantially after the hash has been saved.

If you do need to have a map with your mutable objects as keys, you probably need to go a step back and implement that yourself for the object type. You might event want it to be a Multimap (https://en.wikipedia.org/wiki/Multimap) if you don't want to guarantee that the keys are unique.