NaNs Just Don't Get No Respect

[F i L]

On Saturday, 18 August 2012 at 04:44:16 UTC, Jesse Phillips wrote:
> On Saturday, 18 August 2012 at 01:07:43 UTC, F i L wrote:
>> Your example:
>>
>>    float f;
>>    if (condition1)
>>        f = 7;
>>    ... code ...
>>    if (condition2)
>>        ++f;
>>
>> is flawed in that condition1 is _required_ to pass in sync 
>> with condition2, or you'll get a NaN in the result.
>
> It is not flawed as that is exactly what he said condition1 did 
> until the maintenance programmer made a change which caused 
> this to no longer be in sync with condition2 (most likely 
> fixing a bug as condition1 really should have been false).

It's flawed because condition2 relies upon condition1 to function 
without error. The example, as Walter presented it, is logically 
describing:

     float f;
     if (condition1) {
         f = 7;
         if (condition2)
             f ++;
     }

because the only way Walter's next argument, that "a programmer 
will haphazardly supply a default value where there _should_ be a 
NaN", is in error, because if condition2 _does_ rely upon 
condition1, then there _shouldn't_ be a NaN by the time 
condition2 is reached, as condition2 _should_ be nested (like 
above), and the programmer made a logical mistake (which the 
compiler can warn him about). Remember, NaN in this example is 
only used as error checking to ensure 'f' is assigned before it's 
manipulated.

If however, condition2 isn't intended to rely upon condition1, 
then 'f' needs to be explicitly assigned a usable value before 
condition2, and outside of condition1. Which also negates 
Walter's "haphazardly assigned" argument, because 'f' _isn't_ 
intended to be NaN (so assigning to 0.0f makes sense), and 
condition1 is the only place 'f' is assigned in the example.

The only way code like Walter's example is written, is when the 
coder has made a logical mistake. Which, again, the compiler can 
warn us about:

     float f;
     if (condition1)
         f = 7;
     // f _could_ be unassigned, therefor...
     if (condition2)
         f ++; // ...should be error


Furthermore, in a situation where the value _is_ intended to be 
NaN (for example, to check 'f' for NaN after condition2) then an 
explicit assignment to NaN will help document that intent, and 
help keep a third party from mistakenly assigning it to something 
else at a later date:

     float f = float.nan;
     if (condition1)
         f = 7;
     if (condition2)
         f ++;

     ...lotsa code...

     if (f == float.nan)
         doSomething();
     else
         doSomethingElse();

In this situation, if floats default to NaN and 'f' wasn't 
explicitly defined, a maintenance programmer might not recognize 
the last condition, think "gee, I need to set that to a value in 
case condition1 fails when condition2 does not", and mistakenly 
assign 'f' a usable value, thus introducing a silent bug.