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

[Götz Becker]

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:

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 May 29, 2012 by Götz Becker

[Phillip Brooks]

Maybe use compare elements and then exclude the items you're not interested in; a variation of this:

http://lavag.org/topic/7335-wildcards-with-search-1d-array-prim/page__p__42656#entry42656

[Saverio]

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.

[Götz Becker]

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

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.

[Rolf Kalbermatter]

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

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.

[Götz Becker]

... 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.

[Bobillier]

Perhaps you can use this http://lavag.org/topic/14538-unbundle-cluster-array/page__hl__xnode__fromsearch__1 to separate cluster element and test equality.

Eric

[Rolf Kalbermatter]

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).

[asbo]

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.

[Rolf Kalbermatter]

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.