Movement against float.init being nan

[Walter Bright]

On 8/22/2022 7:16 AM, Steven Schveighoffer wrote:
> One thing that everyone seems to be ignoring is that 99% of the time, when I 
> find out I didn't initialize a float and it's NaN, it's because I didn't 
> correctly initialize it to 0.

Then 1% of the time 0 is the wrong value and you never notice that the resulting 
calculation is off. Whereas with NaN you notice that when there's "NaN" in the 
printed result, it's not hiding.

 > Imagine you are making a 3-d model, and one vertex out of 100k is NaN. How 
will you notice it? A single missing triangle somewhere?
But make that vertex 0, and all of a sudden your model has this weird triangle 
sticking out extending to the origin, and is completely obvious.

C89 did not take NaNs into account for the floating point parts of the C 
standard library. But C99 did, and if the program tries to calculate:

    sin(NaN)

the result will be NaN, guaranteed by the C99 Standard.

If the graphics library cannot handle certain floating point values, such as NaN 
or Infinity, then that should be checked for as part of the call. At least in 
debug builds. It'll be a lot easier than looking for an out of place triangle. 
Most graphical displays seem to have an awful lot of tiny triangles.

If I was writing code that, say, calculated a trajectory of a space craft, there 
is no way it would be acceptable to have default 0 initialization. Even if it's 
right 99% of the time. Because 1% of the time having a hull loss is not acceptable.

P.S. graphics software generally doesn't care about making mistakes. I've seen 
plenty of buggy graphics in video games, and it doesn't matter because it 
doesn't affect game play. But people doing science, engineering, accounting, 
flight controls, etc., care very much about getting 100% correct results. 1% 
going awry is not acceptable.