Jump to content

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


Recommended Posts

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

post-13461-0-45056200-1338920195.png

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

post-13461-0-72053400-1338920203.png

Link to comment

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.

Link to comment

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.

Link to comment

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:

post-13461-0-81584200-1339022129.png

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

Link to comment

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.

Link to comment

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.

Link to comment

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

post-5958-0-80716900-1339071684.png

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.

Link to comment

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.

Link to comment

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.

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
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.