Re: Should NaN be reported as "UNDEFINED" ?

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On a machine with IEEE-compliant floating point interpretations,
> the string "NaN"  (not case sensitive) is a legal floating point
> value.  Thus if NaN occurs in an input data file, the point is 
> not flagged as DF_UNDEFINED.
> 
> Should it be?  
> 
> DF_UNDEFINED usually means some random non-parsable
> junk appears in the field, or perhaps the field is empty.
> 
> I've uploaded a trivial patch that marks input NaN values as
> UNDEFINED, attached to Bug #1490699
> 
> But I'd like to hear whether everyone agrees that this is
> correct behaviour.
> 
> What about infinities ("Inf")?  
> I am inclined to pass those through, since the sign information
> is still present and conceivably a plotting function would want
> to handle +/- Inf explicitly.

I'm inclined to agree with you.  NaN is undefined.  Unless the user wants to flag it as missing.

+/-Inf is part of the extended real number system and part of the IEEE float definition.  It likely is something handled legitimately by most hardware and software these days.  Generally, let it pass on through, I would think.  Especially given the fact that I think there is both a plus and minus infinity in the IEEE definition.  So that would mean you'd need multiple strings to declare that as "missing".

NaN is in the IEEE definition as well, but has no conceptual connection to the real or extended real number system.

I think that is good for 4.2.  But I would like to see eventually flexibility with defining both "missing" and "undefined", with possibly the ability to have more than one definition.  For example,

set missing "Inf" "+Inf" "-Inf" "inf" "+inf" "-inf"
set undefined "N/A" "outdated"

Dan