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.

On 8/23/2022 2:00 AM, claptrap wrote:
> Dont most C/C++ compilers have warnings for initialised variables? I'm sure MSVC did when I was using it, but its 15 years ago now.

I just tried it with gcc. No warning.

On Wednesday, 24 August 2022 at 05:57:38 UTC, Walter Bright wrote:
> On 8/23/2022 2:00 AM, claptrap wrote:
>> Dont most C/C++ compilers have warnings for initialised variables? I'm sure MSVC did when I was using it, but its 15 years ago now.
>
> I just tried it with gcc. No warning.

Most of gcc's warnings, including this one, are not enabled by default. If you compile with -Wall, you will get a warning.

On 8/24/2022 5:17 AM, Paul Backus wrote:
> On Wednesday, 24 August 2022 at 05:57:38 UTC, Walter Bright wrote:
>> On 8/23/2022 2:00 AM, claptrap wrote:
>>> Dont most C/C++ compilers have warnings for initialised variables? I'm sure MSVC did when I was using it, but its 15 years ago now.
>>
>> I just tried it with gcc. No warning.
> 
> Most of gcc's warnings, including this one, are not enabled by default. If you compile with -Wall, you will get a warning.

Fair enough, though that makes it clear that there are many languages called C, and Standard C does not complain about it.

On 8/22/2022 6:19 PM, Steven Schveighoffer wrote:
> I'm curious what all languages do that actually use an initial value?

AFAIK D is unique in using NaN.

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

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

On Wednesday, 24 August 2022 at 18:15:53 UTC, ryuukk_ wrote:
> 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

One could say, "well that's a bug anyways, and now you know you got a bug in your program", and that's why NaN wins over 0, it's annoying, but it is useful

(sorry for 3 successive reply)

On Wednesday, 24 August 2022 at 18:15:53 UTC, ryuukk_ wrote:
> 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

In gdb you can use `select-frame` and inspect the value of locals of the **whole** call stack. Also just `bt` can help as that shows the call args values.