NaNs Just Don't Get No Respect

[F i L]

On Saturday, 18 August 2012 at 14:29:12 UTC, Jesse Phillips wrote:
> On Saturday, 18 August 2012 at 09:32:01 UTC, F i L wrote:
>
>> 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 ++;
>>    }
>
> This greatly changes the semantics of the code. I do not 
> disagree that the example indicates the original programmer is 
> likely wrong and needs to improve the description of his intent.

I agree, and that's my point here. The original example is an 
erroneous presupposition that leads to faulty conclusions. If the 
compiler warned against this error the programmer would likely 
fix the code to a state which prevents the potential bug this 
example was originally intended to illustrate.


> What I disagree on is that it is that complaining that f might 
> not be initialized will force the programmer to think and 
> address the true issue. It is also taking the example at face 
> value. The complexity of the relationship could be harder too 
> see (I don't know what that would be),

I too, don't know of any examples where defaulting to NaN would 
prevent an error where static analysis would not, though I'm 
always open to argument. Given the benefits of static analysis 
and defaulting to 0.0f for class members (which I listed in 
previous posts), I see that position as the one with demonstrable 
benefit.


> and somewhere else where condition1 is set there could be code:
>
> auto condition1 = getmevalue();
> enforce(condition1 && condition2, "Huston this is the 
> problem!");

I don't see how this changes the situation with NaN vs. static 
analysis.