Comparison VI Data Changed - Bug or Documentation misleading!?!

[Götz Becker]

The Data Changed OpenG VI doesn't work with NaNs.

Basically it lacks isNaN checking. Since it is documented as TRUE if the data changed, it should work for NaNs as well.

[crossrulz]

It's the classic "NaN != NaN" scenario

[Götz Becker]

Sure it is... but for me, with my non native english knowledge, the documentation "...that will output a true if the data flowing into it has changed." reads as only a change will output a true. This includes proper NaN checking.

[asbo]

So tweak the VI and post a fixed version for inclusion All it should take is a couple of "Not A Number/Path/Refnum?" nodes in the DBL instances and you're set.

[Götz Becker]

Had to finish some real work... :-)

Here my proposal.

data_changed_DBL_NaN_aware.vi

(Sry about the feedback node... I just don't like the while loop SR any more.)

[asbo]

Using your VI (sorta, I had to rewrite it), I changed the test case, I think the new implementation VI misses (non-NaN) -> (NaN).

I took a couple minutes to play with it, and think this covers each of the possible transition cases.

[Götz Becker]

Ah, damn I should have tested it better... thanks!

[Aristos Queue]

And this, ladies and gentlemen, is why any time you have heard me speak in the last three years, I have harped on one point in almost every speech: the importance of buddying code. Nothing -- NOTHING -- does more to catch bugs and correct architecture mistakes that will bite you in the future than having a second set of eyes look over your code. If you have a team, buddy your code. If you are a lone developer or contractor, find someone else in a similar role in your community and buddy each other's code. It will help A LOT. I promise.

[crossrulz]

I don't see why Gotz's code didn't work. I downloaded his VI and ran with the same case as asbo and it works perfectly for me. Did you break it before running your test, asbo?

[asbo]

And my public smear campaign is foiled...

I mentioned above, I used his snippet (which didn't include the subVI), so I probably didn't wire it up correctly. Sorry I couldn't be a poster boy, AQ

[crossrulz]

Sorry I couldn't be a poster boy, AQ

You are probably still the poster boy since we had to use another buddy in order to find that the first buddy make a mistake. I'm just curious what your code originally looked like in order to get the results you did.

[asbo]

You are probably still the poster boy since we had to use another buddy in order to find that the first buddy make a mistake. I'm just curious what your code originally looked like in order to get the results you did.

It's in the opposite case of the diagram disable structure, so:

The answer is that I wired the "value" input's "Not a Number?" node to the NOR instead of the AND. Alas...

[crossrulz]

So if this goes into OpenG, I would prefer Gotz's implementation (less logic). And Gotz, I prefer the FB node over the shift registers. They look cleaner for some reason.

[asbo]

So if this goes into OpenG, I would prefer Gotz's implementation (less logic). And Gotz, I prefer the FB node over the shift registers. They look cleaner for some reason.

I agree. However, I'd like to spend a few minutes and see if they benchmark differently. I fully expect the compiler to be smart enough to reduce mine.

[Rolf Kalbermatter]

I agree. However, I'd like to spend a few minutes and see if they benchmark differently. I fully expect the compiler to be smart enough to reduce mine.

Maybe LLVM does that, but I doubt that the original LabVIEW compiler did boolean logic reduction. Even then the difference is likely very small in comparison to the time needed for the Variant case for instance. Two logic operations versus six does not amount to many nanoseconds for sure on modern CPU architectures.

And it is clear from a quick glance what asbo did wrong when copying the code. He should have ORed the two isNaN? results, not one of them and the isEqual? result.

[Mellroth]

What about using a simple typecast to U64 before checking diff?

It will however return TRUE for differently represented NANs, but otherwise it should be fine.

/J

[Rolf Kalbermatter]

What about using a simple typecast to U64 before checking diff?

It will however return TRUE for differently represented NANs, but otherwise it should be fine.

/J

That should work if the NaNs are guaranteed to come from LabVIEW itself but could fail because of the reason you mention, if the NaN could come from somewhere else such as a network bytestream.

[ShaunR]

That should work if the NaNs are guaranteed to come from LabVIEW itself but could fail because of the reason you mention, if the NaN could come from somewhere else such as a network bytestream.

That could be overcome with a bitmask check.

[asbo]

That could be overcome with a bitmask check.

Then you'd need to find out if a type cast and mask are faster than logical comparisons. Depends on how much overhead there is in the LabVIEW operators for NaN but hopefully it's pretty ideal.

[Rolf Kalbermatter]

That could be overcome with a bitmask check.

I would almost bet my hat, that that is also what the "Is NaN/Refnum/.." function does. Which makes it likely a similar fast operation as the typecast with following bitmask operation. And because of that I would prefer the explicit and clear use of the Is NaN primitive any time above the much less clear "Advanced Operation" hack, even if it would save a few CPU cycles.

[Götz Becker]

The typecast method will probably always be slower than the direct isNaN check, due to the buffer© of the typecast node. (http://lavag.org/topic/15187-inplace-typecast-possible/page__view__findpost__p__91471)