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

[Darin.K]

@AQ -  You have to bounce a bit in the 2008 standard, but there are two functions minNum and maxNum which point to section 6.2 on how to handle NaN input.  I can not post copyrighted material, but in section 6.2 there is a sentence to the effect that all  operations, other than maximum and minimum, (annoying that they changed nomenclature between sections) should return NaN when one of the inputs is NaN and the output is a floating point number.  That is why all implementations, including LV, correctly return max(x,NaN) = x and min(x,NaN) = x like the snippet I posted.

IR&C explicitly documents its NaN implementation, so I like both the implementation and the documentation.

Any comparison to NaN which returns false does not imply that the complementary comparison is true, NaNs have their own special region in the Venn diagram.  If you find this leaves you in an implementation-specific spot, then I would expect it to be documented, but there is no discussion in the Detailed Help on this matter.  This is why I assume there is a fallback on the underlying code:

If you examine the code and saw min(upper,max(lower,value)) you would say that is great.  There is no explicit decision to handle NaN, simply rely on the implementation of minNum and maxNum.  Undocumented, unintended behavior is a wide open door to flagging this as a bug and fixing it.

I can see the logic behind wanting/expecting NaN's left alone when entered.

I can see the logic behind wanting/expecting the value of the control unchanged when NaN is entered.

I can not see the logic behind wanting/expecting the value coerced to the maximum limit when NaN is entered, I would like an advocate of this behavior to explain it.  (I have given the techno-geek spec argument that no user will care about, there seems to be the sentiment that this is somehow 'natural' or desired and I do not see it).  IEEE specs do not have to be natural or desired, only precise, UI components have the pesky user involved.

Every function except maxNum and minNum behave as follows f(x,y,z) returns NaN if x,y, or z is NaN.  Now a function called coerce(value,upper,lower) could either follow every other function except those two and return NaN if one of its inputs is NaN, or it could deviate from this behavior, document the deviation, and persuade us why it should be a very rare exception.  Deviation from the norm without documentation is a possibility that seems to have been chosen here.

@GregR:  This is the sort of thing that is desired more often than you'd like for a one-off solution, but not as often as you'd like for an XControl.

[AristosQueue (NI)]

Darin: Thanks for the information on the range checking.

[Darin.K]

You're welcome, the only reason I know of that "loophole" is the Max&Min function in LV.  When I first saw that it did not propogate the NaN I was a bit surprised and I think it was an NI engineer that pointed me to the specs.  

Now for the "eat your own dogfood" argument:  try entering 'NaN' into the limit values in the Data Entry dialog itself.  The default handling isn't even good enough for its own dialog.  The irony is that the default handling would be perfect for the Upper Limit (NaN => Inf makes perfect sense, no upper limit), but it is overridden.

I think the only solution is the earlier listbox suggestion:  NaN handling: Ignore (leave them alone), Coerce Up (current behavior),Coerce Down (lower limit), Coerce to Default, Block (do even let the user enter 'NaN' or at least revert to old value).

[altenbach]

 > AQ (here😞 IEEE standard is that operations for comparison on NaN are always FALSE

No, that's not quite true either. Some comparison operations with NaN return TRUE.

(For example a "not equal" comparison of a regular number and NaN returns TRUE, not FALSE, even in LabVIEW ;).)

[altenbach]

For the current idea, if implemented, it should be complete.

There should be three checkboxes that optionally reject entering (1) NaN, (2) Inf, or (3) -Inf.

[Darin.K]

AFAIK 'Not equals' is not one of the prescribed comparisons, 'equals' is.  Equals returns FALSE as prescribed by IEEE, then LV or whatever other language can procede to perform the not or other operations.

I am not convinced of the need for three checkboxes here.  +/-Inf are perfectly specified.  No ambiguity in greater than, less than or equals comparisons.  Entering +Inf or Inf and getting the maximum allowed value strikes me as a totally natural UX.  Blocking Infs may have a valid use case, but I would weigh them totally separately from NaN.  (I guess my point is that NaNs are really totally different animals than numbers). By applying the faulty well NaN is not [less|greater] than the [upper|lower] limit so it must be [greater|less] than it you can convince yourself that NaN should coerce to any value.

 And I really think I would block both or neither, not sure I would see myself blocking +Inf but not -Inf.

[ghighuphu]

I'd like to retain entered NaNs. No coercion. I see what IEEE defines, according to your comments, but I don't agree as well, that NaN should be coerced to the highest value.