Add a NaN constant to the numeric palette

[altenbach]

It is not obvious that a NaN numeric constant can be created by simply typing "NaN" as value. What we see are weird constructs, e.g. "zero divided by zero" or "square root of -1" to generate a NaN on the diagram.

I suggest to add a NaN diagram constant to the numeric palette to make it more obvious.

(This is just a quick draft. Of course it should be matched in color and design to the other constants)

[Ray.R]

Wow... That was quick.

I'm missing out on a whole bunch of Kudos 😉

[Brian_Powell]

Okay, I'll bite.  I've shot down this suggestion a few times when it's been made internally.  I will proudly admit to being wrong if the community votes this idea up such that we implement it.

My main question is, "What do you plan to do with this constant?"

I worry that the average user who doesn't know that he or she can type "nan" into a constant will also not know what to do with the constant.  Or worse, will assume you can do something like compare it for equality or numeric order.

Don't get me wrong; there are many good uses for NaN.  But I'm not sure it's worth adding a constant to the palettes when you can just drop a numeric and type "nan".

[altenbach]

A typical use is to create gaps in graphs and charts, where we need to replace certain values by NaN. (using either "select" or "replace array subset", for example).

Yes, comparison operations with NaN are tricky, thats why have this function. Knowing how to type NaN as a value does not necessarily imply knowledge of comparison either, but I see your concern of possibly lowering the bar for NaN usage. Maybe something could be said in the context help.

[ReneW]

I really missed this feature as I started with LabVIEW.

But it is unnecessary (really). Just type nan or +inf or -inf into a numeric constant... and there is the desired NaN, +Inf or –Inf.

Unfortunately, it is not obviously that you have to type nan into a numeric field. As I started with LabVIEW I did some work around like 'division by 0'.

I suggest:

• Do not add NaN to the numeric plate. On the contrary: Remove the +inf or –inf. (This would clean up the numeric plate a little bit)
• But: Do Improve the Context Help. Add a note in the Context Help of the 'numeric constant'. It should be obviously that a constant could be set to NaN, +Inf or –Inf by writing nan, +inf, -inf. This would give a much bigger help to many people than adding an additional item to the numeric plate.

[donkdonk]

It never came to my mind to just type NaN in a constant. Indeed, I also used the divide by zero trick and then change to constant.

I must say it's been a while now I needed a NaN, but still kudoos.

I remember there used to be an easier access to NaN in a version far back, or am I mistaken?

[Ray.R]

I disagree that it is unnecessary.  So many people do weird tricks to generate NaN that it is obvious that they do not realize that you can simply type it into a double constant.  Same with +/-Inf. 

Kudos!

[AristosQueue (NI)]

> Same with +/-Inf.

And we already have constants for positive and negative infinity. If those have utility, I think that NaN constant would have utility.

> I remember there used to be an easier access to NaN in a version far back, or am I mistaken?

I only know back as far as LV 6.0. To the best of my memory, there has never been a NaN constant or anything like it in the palettes.

[Darin.K]

I'll wager that the +/-Inf constants owe their existence more to the special symbol than to their relative utility.  I practically never use the +/-Inf constants because I tend to drop very few constants from the palettes.  Most are created via 'Create Constant' so I just type the value.  As a bonus, the value can be changed later simply by typing.  I am assuming the idea here is for a fixed NaN constant, not a DBL constant pre-populated with NaN.

I try not to let perfection be the enemy of the good, but I feel that this is a half-step that could be skipped in an overall improvement of the numeric constants.  I think that numeric constants should have glyphs that indicate data type.  These should be active for floats with a pull-down menu for the values +/-epsilon, +/-Inf and NaN.  This would make it consistent with the path constant and free up some palette space as well.

[Ray.R]

Darin.K:  "I think that numeric constants should have glyphs that indicate data type.  These should be active for floats with a pull-down menu for the values +/-epsilon, +/-Inf and NaN.  This would make it consistent with the path constant and free up some palette space as well."

Makes sense. 

Why not place them under "Constants" (instead of Math & Scientific Constants)?

[Dirk_De_Mol]

There are many uses for NaN's outside the pure mathematical "illegal operation". I have used it many times, specifically:

1) As mentioned before, to show gaps in graphs.

2) For measurements, NaN might mean "no measurement was available". This is different than "out of range". A measurement can also be a computed value and NaN's make it really easy to tell the user not to trust the value.

3) As a default value when reading numbers. In the Fract/Exp String to Number function, I use this all the time instead of the "0" as default. If the string is empty, I get a NaN. For example, when reading a spreadsheet file with customer supplied upper and lower limits, an empty field meant "do not test for this limit". I could have implemented this with a cluster of {value, "use this limit" boolean}. But one float was a lot more convenient.

So yes, I would like to see this as a constant on the palette.