VI reference comparison bug

[Albert-Jan Brouwer]

Comparison of VI references has been broken going from LabVIEW 7.x to 8.

See attachment.

Download File:post-372-1130703059.vi

[PJM_labview]

Comparison of VI references has been broken going from LabVIEW 7.x to 8.

See attachment.

Download File:post-372-1130703059.vi

Checked it on my machine, and I got the same behavior.

This is a pretty bad one.

PJM

[Yair]

I'm not sure what the problem is. The equal? node has been made smarter. Until now, it couldn't compare different references to the same object if the references were strict and non-strict or if they were opened seperately. Now it can.

Page 58 of the upgrade notes -

The Comparison functions have the following improvements and changes:

[David Boyd]

Checked it on my machine, and I got the same behavior.

This is a pretty bad one.

PJM

Are we sure this is incorrect behavior? Is the definition of equality whether the refnums refer to the same VI object, or the same instance of the VI including its dataspace?

(Or am I just adding noise to the discussion?)

Dave

[Albert-Jan Brouwer]

Are we sure this is incorrect behavior? Is the definition of equality whether the refnums refer to the same VI object, or the same instance of the VI including its dataspace?

Well, I suppose if it were new functionality, it would be up to NI

to choose the behaviour. Even so, it would be a rather unusual

choice: in all OO languages, different instances of the same

class are not equal.

But this is not new functionality, under previous versions of

LabVIEW you could also compare VI references, and the

behaviour was different than under LabVIEW 8.0: instance

equality instead of class equality.

So the new behaviour breaks existing code, which is how I

found out about it.

[m3nth]

I'm guessing that the new behavior of the equals operator was implemented for other (more common I'm guessing) types of comparisons which were having problems (in previous versions) when two references were passed to an equals operator.

You can always change the code you have now that's broken to the other comparison code you showed--typecast to an integer and check to see if they're exact. However, previous to the new functional implementation of the equals operator, you could not do the internal check that LabVIEW could perform internally to see if the references point back to the same object. With the new behavior in v8.0, this internal check is extracted to the user via the equals operator, so you don't need a special NI VI to do the same thing (see the NI thread and attached VI).

http://forums.ni.com/ni/board/message?boar...hreading&page=1

Since the equals operator can only do one thing or the other, I think the behavior in v8.0 is probably better in the long run for the average user because there is extra functionality available via the equals operator that wasn't there before.

[Albert-Jan Brouwer]

However, previous to the new functional implementation of the equals operator, you could not do the internal check that LabVIEW could perform internally to see if the references point back to the same object. With the new behavior in v8.0, this internal check is extracted to the user via the equals operator, so you don't need a special NI VI to do the same thing (see the NI thread and attached VI).

Though having such functionality can indeed be useful, I don't see why it would necessarily have to break the existing semantics. Why not add an additional comparison mode to the equals operator like we already have for arrays: you can select whether or not to compare aggregates. Preferably in a manner that is visually explicit. It is much better to clearly discriminate different types of equality than to leave the programmer guessing.

If you think this is nit picking, think again. Something as common as comparing two clusters will probably not do what you think it does, if the clusters contain floating point numbers. Consider what happens when the clusters are identical with the numbers set to NaN. For such situations I'd like to have the option to test for binary equivalence instead of numerical equivalence.

[...]I think the behavior in v8.0 is probably better in the long run for the average user because there is extra functionality available via the equals operator that wasn't there before.

For references to the same non-reentrant VI, I think the new behaviour is reasonable since there is no operational way of discriminating between two of those. However, for references to reentrant VIs this is not at all true. Reentrant VIs can maintain unique internal state (e.g. in shift registers) per reference so that a call by reference with the same inputs yields different results depending on which instance you called. Such usage is not at all pathological: it is one of the very few ways in which you can avoid code duplication when programming in G.

[m3nth]

Why not add an additional comparison mode to the equals operator like we already have for arrays: you can select whether or not to compare aggregates.

I think this is the best idea yet... perhaps you could add it to the wish list. I think that would fall into the category that NI seems to not do too well at sometimes... something along the lines of creating great idioms and widely implementing and enforcing them. The idiom is there (compare / don't compare aggregates, change logic operation, etc etc), but then it's not widely implemented to the full set of functions available.

[David Wisti]

This not only effects comparison. You can add Search 1D Array to list of bugs, ahem... changes. See attached VI. Yes, I just spent most of the day trying to find out why my code worked fine in Labview 7.0 but acted strange in 8.0.

Download File:post-319-1131657927.vi

[m3nth]

I guess it's unfortunate that NI implemented this 'bug' in such a methodical and thorough fashion... changing the underlying routine when two references are compared--you'd think they did that on purpose or something.

[David Wisti]

I wonder if this effects any other type of reference? Or is it just isolated to vi references?