Re: How to check a Float for NaN

["Randy Brukardt" <randy@rrsoftware.com>]

"Adam Beneschan" <adambeneschan@gmail.com> wrote in message 
news:840855a9-bda8-44b7-ab53-e157b4fc1d31@googlegroups.com...
On Tuesday, May 27, 2014 5:35:26 AM UTC-7, Maurizio Tomasi wrote:
>> > That is, I see no sensible reason for NaNs or infinities -- they're 
>> > just ways of deferring detection of bugs. I would have hoped that Ada's 
>> > moved beyond that, just like it has for integers.]
>>
>>
>>
>> Being a scientist working with large chunks of data, I find NaNs useful 
>> in a number of situations.
>> I work in a domain (observational cosmology) where we need to deal with 
>> sky maps containing
>> ~10^7 pixels (you can think of a "map" as a 1D vector where pixels on the 
>> sky sphere are
>> ordered according to some rule). Not every sky direction can be sampled, 
>> because of a number
>> of problems (in the instrument, in the observational strategy, in the 
>> data reduction pipeline, etc.)
>>
>> Therefore, in my Python+NumPy codes I always mark such directions using 
>> "quiet NaNs".
>> If I have to combine two maps in order e.g. to take their average, the 
>> usual rules for
>> combining NaNs are be exactly what I want. Writing in Ada what I actually 
>> write in Python:
>>
>>   for I := 1 to N do
>>     Average_Map(I) := 0.5 * (Map1(I) + Map2(I));
>>   end loop;
>
>Well, that's actually half Pascal and half Ada, but we understand what you 
>mean.
>
>But you don't need NaN's built into the language in order to get that sort 
>of functionality.  In
>Ada (or C++ or any other language that supports operator overloading), it's 
>simple enough
>to define an "optional floating-point" record type consisting of a float 
>and a Boolean, where
>the Boolean indicates "missing data", and define operators that produce 
>"missing data" if
>either operand is missing.  So you could still write mostly the same code, 
>except that
>converting to or from a float, or from a floating-point literal, takes a 
>little extra code.

If one has
    function "+" (Right : Float) return Optional_Float;

then the "extra code" is just preceeding the float value with a "+". Hardly 
earth-shaking. (And the usual complaint about using "+" as a conversion 
operator is a non-problem here as these are numeric types).

I much prefer this sort of solution (where the missing values are explicitly 
treated) rather than using some sort of magic number (a NaN being an extreme 
version of that). The name alone tells you that it doesn't belong in a 
numeric type -- since when is something that is "not a number" belong in a 
type defining numbers?

As usual, this is mainly a case of premature optimization (preverting the 
hardware to handle something that's a rare need -- I wonder how much faster 
float hardware could be if it didn't have to mess with NaNs? I know that 
they impacted our software floating point quite a bit even though I made no 
attempt to actually do anything useful with them.)

                                 Randy.