Movement against float.init being nan

[drug007]

On 8/22/22 17:16, Steven Schveighoffer wrote:
> On 8/22/22 9:33 AM, drug007 wrote:
>> For example, user has a callstack where called functions has these 
>> return values:
>>
>> float.init == 0                float.init == NaN
>>
>>      13 <==  wrong result detected here  ==> NaN
>>      0                     NaN
>>      39                    NaN
>>      56                    NaN
>>      9 <==   wrong initialization here   ==> NaN
>>      12                    12
>>      0                     0
>>      0                     0
>>
>> In which case you find the reason faster?
> 
> Callstack printouts don't look like that. Plus, what if you don't have 

Of course it is not a real call stack

> the call stack available for inspection? And even if you do, that 9 

you can use printf debugging

> might be just as obviously wrong as the NaN, negating any real benefit.
>
Yes, that's the point! 9 might be obviously. But NaN would be obviously.

> 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.
> 

I don't agree. There are cases where default initialization is non-zero.

> So yes, when a lack of initialization somewhere in some code has 
> happened *and is a mistake*, a NaN starting value can make things 
> slightly easier, as long as you have everything instrumented, and can 
> use a debugger. But *when* it happens is reduced to near zero if the 
> default value is the expected 0.
> 

you are exaggregating a little. instrumentation is not required and 
printf debugging is always available

>>>> 2. x is default initialized to 0. bar(0) may exhibit problems, but 
>>>> these problems won't necessarily be noticed.
>>>
>>> Just like NaN.
>>
>> No. NaN is not a number but zero is a number. zero may be both wrong 
>> and right value. NaN is never right result. To check if zero is right 
>> result you need manually calculate it. In case of NaN all you need is 
>> to take a look at it.
> 
> As I've mentioned, you don't always see the NaN, just like you don't 
> always see the 0.
> 
> 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.
> 

Yes, in this specific case you right. But what if some of your valid 
vertices might be zero too?

> -Steve