Movement against float.init being nan

[Walter Bright]

On 8/22/2022 6:16 PM, Steven Schveighoffer wrote:
>> The point is, since 0.0 is a common value for a floating point value to be, 
>> just when does it become obvious that it is wrong? Are you really going to 
>> notice if your computation is 5% off? Isn't it a *lot* more obvious that it is 
>> wrong if it is NaN?
> 
> This is a highly dependent situation. It could be 0, which is 100% off. It could 
> be 5%. It could be 0.0001% off, which might actually not be a problem that is 
> noticed.

Of course. And NaN is always wrong.


> If instead it printed NaN I would have ignored that price, and just put 0 in *at 
> a later calculation* to prevent errors showing up in the final proposal. Then I 
> would have missed the fudge factor someone sneaked in.

If you ignore the NaN value, you can hardly then blame it for missing the fudge 
factor.


> But I think in terms of *frequency*, a default value of 0 for a 
> float that isn't explicitly initialized is 99% of the time correct, which means 
> you will have *less of these problems to find*.

See my other post about having code work by happenstance 99% of the time being 
not what D is about.


>> 0.0 is hardly a rare value, even in correct calculations. NaN is always wrong.
> 
> It's not rare because it's a very very common initial value.

0.0 a commonplace value everywhere.


>> NaN propagates. 0.0 does not.
> Someone has to look at it, to "obviously" see that it's wrong.

If you never look at the output, no bugs will be noticed in it anyway.


> Something with semantic capabilities has to be used to prove it's not set before 
> being used. Is there anything besides the compiler front end that can do this?

You need data flow analysis for that. I didn't put DFA in the front end because 
that makes it slow for little benefit.