Movement against float.init being nan

[ryuukk_]

On Wednesday, 24 August 2022 at 18:11:57 UTC, ryuukk_ wrote:
> On Wednesday, 24 August 2022 at 05:54:59 UTC, Walter Bright 
> wrote:
>> 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.
>
> That's the best answer possible, i used to be annoyed by float 
> not being 0 by default, but as i learn more and read different 
> takes on it, it makes sense, and i don't mind anymore
>
> The main issue is to get used to it, it takes time if you use 
> other languages that defaults to 0

I want to point out that, just like with the GC, it is not the 
panacea, if you have a NaN in your result, good luck finding what 
is the root of the issue/bug in your program, or library.. it is 
during moments like that that i still prefer it being 0 by 
default, so everyone is on the same page