allow blocking of NaN in numeric data entry

[SFK]

Recently, I discovered an annoying "feature" of LabVIEW: if you limit the data entry of a floating point numeric to a maximum value with coercion enabled, entering NaN to that numeric will be coerced to the maximum that you set in the data entry dialog.

I already reported that as an unexpected behaviour, but after some more thinking, I dare to go even further and propse:

allow the blocking of NaN in floating point numeric data entry

The logic needed should not be much more than a finger exercise, as string controls already allay to discard CR/LF with the "limit to single line" property.

Best regards,

Sebastian

[fabric]

NaN = maximum? How odd!

Perhaps a better implementation would be for NaN to revert to the default value for the control.

Kudos - not because I've ever really needed to block NaN, but because the current behaviour seems illogical.

[AristosQueue (NI)]

Fabric: NaN = maximum? Reasonable choice. NaN is, after all, undefined behavior, so however LabVIEW defines it is -- by definition -- correct.  The user specified that the value should be restricted to within a given range. An other out-of-range value is input. For all other out-of-range values, LabVIEW pins to either the minimum or maximum. Is it more correct to say "NaN gets special behavior" or is it more correct to say "NaN does what every other value does and goes to one of the end points" ?

SFK: Your request to add additional features to detect NaN and handle it is a reasonable request, but I wouldn't make a simple checkbox for "Discard NaN entry". I would make it match the options of the other rings: Ignore, Coerce, and maybe add an additional option for NaN: Allow. Sometimes I have wanted users to enter valid data within a range or enter NaN for data they do not have. I've had to code that using the Event Structure rather than rely on the built-in limiters.

To everyone: If you have the need for this feature, a workaround exists today. It is easy to build the range checking for numerics using the Event Structure to get whatever ignore/coerce behavior you desire. The built-in Data properties just make it simpler. LabVIEW could conceivably add them in the future, but I suspect that whatever we add, there will always be edge cases where users will want more fine grain control over data entry. For that, the Event Structure and the Value Changed event is your friend. Capture the Value Changed event for the control, check the new values, and then use either a local variable or the Value property (NOT Value (Signaling)) to set the value that you wish the user had entered.

[Darin.K]

NaN is not equivalent to "all bets are off" when it comes to floating point operations and therefore a license to decide what is to be expected or intended behavior.  In fact, this coercion operation falls squarely into well established rules for NaN.  The two functions Maximum and Minimum are specifically defined to favor numbers so max(number,NaN) = number (try it with the max and min comparison function).  That explains the result of the coercion.  min(max(NaN,lower limit),upper limit) = upper limit.

I agree the current behavior is annoying, I do not like choosing to coerce to an increment of 0.1 or 0.5 while ignoring the limits and having NaN morph into Infs.

With the explanation, "We are following the IEEE guidleines for implementing the maximum and minimum operations so the result is consistent those guidelines" then it is palatable.

But the explanation:  "Yee Haw!  We are from Texas and whatever we decide the expected behavior is, that dern-well is what the expected behavior is.  Y'all got a problem, take it up with Mr. Smith and Mr. Wesson" is a little less satisfying.

Many issues here:

1.  Users entering NaN into a control is bad mojo IMO

2.  Strictly following IEEE guidelines is admirable to a select few, but most users would probably prefer something a bit more transparent here.

3.  Event structure handling is an annoying developer exercise leading to a suboptimal UX.  It would be much more satisfying on all levels if say 'NaN' entry was blocked from the get-go by not even allowing the letter 'N' to be entered to start a number instead of the current behavior of waiting until the user has entered 'NaN' only to find the value rejected or changed to some other value.

tl;dr :  I suggest NaN in should be NaN out, do not coerce, do not pass Go, and do not charge us $200.  (Haven't played the game in a long time, but with inflation you probably collect more these days....).  Look no further than the In Range & Coerce function for an example of this behavior.

[AristosQueue (NI)]

NaN is equivalent to "all bets are off." Try comparing with the Less Than and Greater Than prims. They both return false. So when checking for range bounds, either end is acceptable.

IEEE standard is that operations for comparison on NaN are always FALSE, so behavior for "Is In Range?" is always FALSE. The handling of that undefined and each operation is expected to deal with NaN as appropriate for that function.

[AristosQueue (NI)]

>  I suggest NaN in should be NaN out, do not coerce

Lovely suggestion except that you have a control that is defined to only allow in-range values. So any suggestion you'd like to make for the current behavior has to fall within that requirement. Allowing NaN isn't an option -- it isn't within the range.

[Darin.K]

Repeating myself:  The IEEE spec explicitly favors numbers over NaNs in the maximum and minimum functions.  Did you try what I suggested?

I never mentioned greater than or less than, obviously that is not how the range checking is implemented.  Coercion to an increment clearly propagates a NaN to the range checking as well.  You could also have a valid max/min check that pegs NaN to the lower bound. In Range and Coerce uses Greater Than/Less Than, you should also test what it thinks NaN coerces to.  

The built-in coercion is simply a convenience for the user, not a valid range checker.   So  many other ways to get a value in there that is not coerced (locals, properties, wires, etc.) that it does not make sense to rely on it at all.   As such, I say leave NaN alone like the IR&C function.   Far better to let the NaN propagate and handle it as such no matter how it enters the wire.  If I enter a huge number, I know I was trying to enter a huge number and the program nudges me to the largest value allowed.  Likewise for small numbers.  NaN provides no information (by its very design and specification) why even try to guess what the intention is?  Let me see the NaN and warn the user or ignore the value as I see fit.

My point is that AQ is arguing that a choice was made and that it is reasonable.  I argue that no choice was ever made, rather the behavior is a side effect of the implementation of the range checking (ie. using the max/min functions) and therefore accidental.  I think the current method is unintuitive for users and unhelpful.  

(As to this idea, I am not sure.  I want NaN's left alone, not sure I see a reason to exclude them).  

[GregSands]

What about this - defining a Value Change? event that filters the input?

[Darin.K]

I think I half-like the value change filter event, for this and other controls.  What stops me short is that the value must be entered, then rejected.  If NaN is going to get blocked, I would prefer the beginning 'N' or 'n' not be allowed in the first place.   Have to think about this one a bit, I'll probably post over there...

[AristosQueue (NI)]

> I never mentioned greater than or less than, obviously that is not how the range checking is implemented.

Actually, that is how it is implemented. The primitive tests against one bound, gets a false and says "well, then coerce to that bound". In Range & Coerce uses the comparison operations. If LabVIEW started returning the other bound, that would be just as correct from IEEE definition.

> The IEEE spec explicitly favors numbers over NaNs in the maximum and minimum functions.

I don't know of anything in the standard that specifies it. The Wikipedia overview https://en.wikipedia.org/wiki/IEEE_floating_point does not mention it. I have not read through the full 70-page document

http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=4610933

but I don't think NaN's behavior for range conversion is ever specified. In fact, I'm pretty sure it is defined only through its comparison operations, which return false always. An application is free to handle that fact in any way that it wants.

[GregSands]

Darin, you could block the entry of 'n' or 'N' with a Key Down? event.  Thinking about it further, the idea of a small set of Filter Events "bound" to a control seems quite appealing.