Comparing Clusters with NaN elements

[softball]

Hi Altenbach

You are obviously right.

NaN is not always a unique bit pattern. But sometimes it is. And the LabVIEW constant NaN is unique and you can compare it using the Flatten VI. A direct compare will fail though.

But this is nothing different from trying to compare two floating point values in general. Testing for equality is a risky business.

A LabVIEW NaN display can have different bit patterns. Dividing 0 by 0 gives a NaN result. But it is not the constant NaN value.

Thanks for the clarification.

[altenbach]

Yes, if we know the genealogy of where the NaN came from, we should be relatively safe. In the most general case it is dangerous.

One exception is that you can use "NaN" as key to a map and it will not care about the exact bit pattern. You will not get different entries depending on the NaN flavor.

[softball]

Hi again

NaN is one of LabVIEW's secret features.

I love this behavior. Like the good old lift pen for plotters  :

I didn't know of the map related feature. Thanks for the tip.

Regards

[santo_13]

---

@realronaldwarner wrote:

Since NaN is never equal to itself, using a simple equality check won’t work.

Instead, you found that comparing individual elements within the cluster gives you a detailed output showing which specific elements differ, which is really helpful. Pre-conditioning your data by converting NaNs to zeros before the comparison is a great solution! This way, your comparison will work as intended, allowing you to properly activate or deactivate the Save button. Nice job troubleshooting!

---

Definitely sounds like a bot.

[paul_a_cardinale]

If everything in the clusters is numeric, you can use this.

[altenbach]

---

@paul_a_cardinale wrote:

If everything in the clusters is numeric, you can use this.

---

There is a reason I asked early on:

"What kind of cluster is it? Mixed? All numeric? all scalar DBLs, etc?"

And the answer was:

"The issue is that this is large complex cluster with nested clusters containing arrays, and NaNs are used as placeholders for some of the data, especially optional values that the use rmight update."

So this will probably not work well. My suggestion was to use another sentinel value for "missing", such as -1, "Inf", empty array, special string, ... is probably more useful.  (whatever is guaranteed not to be locally valid data for the datatype: (un)singed integer, floating point, complex, etc). Maybe the cluster could have a boolean "Changed?" that is set to true by any event or mechanism that modifies data and back to false when read.

It is hard to give specific advice for a generic question.

(Back in the eighties-nineties, I did a lot of statistics using SAS and they had a special value for "missing" which was different from e.g. NaN. Missing values were correctly handled as part of the analysis. I always wondered why LabVIEW did not have an orange "missing" constant, but that's not part of the IEEE specs, I think)

[BertMcMahan]

---

@littlesphaeroid wrote:

The issue is that this is large complex cluster with nested clusters containing arrays, and NaNs are used as placeholders for some of the data, especially optional values that the use rmight update.

Pre-parsing it is just not worth the trouble (for now), so I'm going to forge informing the user that the data has changed.

It does make we wish there were a more general tool for this type of comparison, that accepted, at least optionally that NaN = NaN.

---

You may be able to make one of these yourself. Look at the "Sort 1D Array.vim" function. It lets you pass in a custom "Less than?" argument. You can probably make your own "Is equal?.vim" function, and in the "numeric type" frame, have a check for isNaN? to get the behavior you want. I'm not quite sure how to iterate through your own cluster and recreate a new one, but maybe there's a way 🙂

[JÞB]

---

@altenbach wrote:

---

@paul_a_cardinale wrote:

If everything in the clusters is numeric, you can use this.

---

There is a reason I asked early on:

"What kind of cluster is it? Mixed? All numeric? all scalar DBLs, etc?"

And the answer was:

"The issue is that this is large complex cluster with nested clusters containing arrays, and NaNs are used as placeholders for some of the data, especially optional values that the use rmight update."

So this will probably not work well. My suggestion was to use another sentinel value for "missing", such as -1, "Inf", empty array, special string, ... is probably more useful.  (whatever is guaranteed not to be locally valid data for the datatype: (un)singed integer, floating point, complex, etc). Maybe the cluster could have a boolean "Changed?" that is set to true by any event or mechanism that modifies data and back to false when read.

It is hard to give specific advice for a generic question.

(Back in the eighties-nineties, I did a lot of statistics using SAS and they had a special value for "missing" which was different from e.g. NaN. Missing values were correctly handled as part of the analysis. I always wondered why LabVIEW did not have an orange "missing" constant, but that's not part of the IEEE specs, I think)

---

IEEE never did define SeV (Sentinel Value) in the 754 specification. 

I would love to see a discussion on how SeV would behave. 

We know only a few things about NaN...it is not a number... and it may be signaling...

In real world we sometimes see something that MUST BE A NUMBER bur has no determined magnitude.  SeV!  There is room for a number of undefined magnitude in floating point represention.

[paul_a_cardinale]

This works for any cluster:

Once a NaN is packaged in a variant, the rules about comparing NaNs are no longer applied; all NaNs are considered equal.

However this could be construed as a bug, and may be 'fixed' in the future.

[softball]

Hi Paul

You are right, and you are wrong.

'To Variant' works like 'Flatten To String'. It converts a NaN to a representation that can be compared directly.

However, if the NaN's involved are binary different as shown in the case above then a NaN comparison will still fail.

But interesting. Maybe a 'To Variant' is faster than 'Flatten To String'.

Regards