NaNs Just Don't Get No Respect

[Don Clugston]

On 20/08/12 22:21, cal wrote:
> On Monday, 20 August 2012 at 19:28:33 UTC, Peter Alexander wrote:
>> On Sunday, 19 August 2012 at 22:22:28 UTC, Walter Bright wrote:
>>> > I find it more likely that the NaN will go unnoticed and
>>> > cause rare bugs.
>>>
>>> NaNs in your output are pretty obvious. For example, if your
>>> accounting program prints "NAN" for the amount on the payroll
>>> cheques, someone is guaranteed to notice. But if it's a few cents off
>>> in your disfavor, it might take you years to discover there's a problem.
>>>
>>> Critical systems also would find a NaN command a lot easier to detect
>>> than an off-by-two command, and would be able to shut down and engage
>>> the backup.
>>
>> The problem is that it's easy for even NaN's to be filtered out.
>>
>> float x = 0.0f;
>> float y; // oops
>> float z = min(x, y); // NaN has disappeared, unnoticed!
>>
>> My argument is that conservative compile time errors on uninitialised
>> variables are more likely to catch these errors.
>
> I just tried this:
>
> float a, b = 10;
> writeln(min(a, b), ", ", fmin(a, b));
>
> Result:
> nan, 10
>
> I think that is incorrect - both should give NaN. The scientific viz
> software I use at work returns NaN for any numerical operation on NaN
> values, means, smoothing, etc.

No, it's the other way around.
The IEEE 754 standard defines min(x, NaN) == min(NaN, x) == x.

According to the C standard, fmin() should be returning 10, as well.
There is a bug in fmin().

However min() and max() are extremely unusual in this respect. Almost 
everything else involving a NaN returns NaN.