Jump to content

Easy way for checking equal/not equal for mixed clusters without IEEE 754 comparison rules?


Recommended Posts

Hi,

is there an easy way for checking a mixed cluster for equality, ignoring the rules for floating point comparison (NaNs)?

I just want to check if the data I receive is new or not. My current idea is:

post-1037-0-34041400-1338282727.png

Loosing type safety and the buffer allocation is for my current use case ok (slow and non RT), but I wonder if I miss something.

Edit: A colleague mentioned that a "to variant" does the some "trick" but might be faster... I guess I'll have to benchmark a little.

Edited by Götz Becker
Link to post

Which "rules for floating point comparison" were you referring to? I'm assuming by the inclusion of NaN in parenthesis you're referring to comparing against NaN. However, there is a more general rule: comparing floating point numbers using Equal or Not Equal is almost always a bad idea and will not always work. Thus, if your clusters contain floats, the top two approaches are null and void. Which makes the choice kind of simple.

Link to post

I updated my usecase example to clarify more what I am looking for:

post-1037-0-90267800-1338303379.png

Basically I do want to compare the cluster raw contents against each other. The flatten to string works but I hope that it can be made more efficient and elegant.

Updating a custom routine for all cluster elements when the cluster changes and implementing the isNaN for both sides is cumbersome and might be forgotten.

Link to post

I updated my usecase example to clarify more what I am looking for:

post-1037-0-90267800-1338303379.png

Basically I do want to compare the cluster raw contents against each other. The flatten to string works but I hope that it can be made more efficient and elegant.

Updating a custom routine for all cluster elements when the cluster changes and implementing the isNaN for both sides is cumbersome and might be forgotten.

Actually this is not going to fly well. While LabVIEW does use a so called canonical bit pattern to indicate NaN, NaN is defined by IEEE in such a way that an entire range of bit patterns result in a NaN value and LabVIEW does recognize this correctly when looking at a floating point numeric. So depending where your NaN comes from they might be each time NaN but not contain the same bit pattern.

Link to post

... So depending where your NaN comes from they might be each time NaN but not contain the same bit pattern.

The data comes from a fixed set of subsystems, mostly LabVIEW-based. This code fragment comes from a proxy style application which tries to reduce load to the backend data storage (TCP connected, 400GB ringbuffer) in which itself is a fine grained isNaN check in the floating point transient recorder.

Link to post

The data comes from a fixed set of subsystems, mostly LabVIEW-based. This code fragment comes from a proxy style application which tries to reduce load to the backend data storage (TCP connected, 400GB ringbuffer) in which itself is a fine grained isNaN check in the floating point transient recorder.

Well, that doesn't say if it is guaranteed that each of those produces the LabVIEW canonical NaN number which is 0xFFFFFFFF. IEEE only specifies that any number with an exponent where all bits are set, and a mantissa with at least one bit set equals NaN. The sign bit is irrelevant for NaN. All exponent bits set and the mantissa is 0 means Infinitive, and here the sign bit has of course a meaning.

So any number resulting in bit pattern s111 1111 1qxx xxxx xxxx xxxx xxxx xxxx (for 32 bit float) and with at least one bit of x set can be NaN. The s bit is the sign bit which for NaN is not relevant and the q bit is the quiet bit, which should indicate if the NaN will cause an exception or not (for most processors a set bit will be a silent or quiet NaN).

Link to post
So any number resulting in bit pattern s111 1111 1qxx xxxx xxxx xxxx xxxx xxxx (for 32 bit float) and with at least one bit of x set can be NaN. The s bit is the sign bit which for NaN is not relevant and the q bit is the quiet bit, which should indicate if the NaN will cause an exception or not (for most processors a set bit will be a silent or quiet NaN).

Just as trivia, LabVIEW does not differentiate quiet NaNs - I remember finding this out after parsing a dataset which did require differentiation.

Link to post

Just as trivia, LabVIEW does not differentiate quiet NaNs - I remember finding this out after parsing a dataset which did require differentiation.

Actually this is not so much something that an application does as much more something which a CPU does. If the quiet bit is cleared (or set for CPUs that use it a signaling bit) they can cause an FPU Exception. An application can then install an exception handler to catch them for calculation results and turn them into quiet NaNs which the FPU is supposed to pass through as quiet NaN in any further operation in the FPU. For LabVIEW it doesn't really make much difference as LabVIEW simply implements the NaN handling according to IEEE. If it uses the exception support from the CPU or not is irrelevant for the LabVIEW user, as we simply get the results and don't have a mechanisme to further get informed about exceptions.

A LabVIEW NaN is explicitedly with all bits set, but it will treat any number whose exponent is all 1 and its mantissa having at least one set bit as NaN.

Link to post

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.