Jump to content

VI reference comparison bug


Recommended Posts

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:
Link to comment
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

Link to comment
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.

Link to comment

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.

Link to comment
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.

Link to comment
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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.