On Monday, 29 April 2024 at 08:12:22 UTC, Monkyyy wrote:

Yep, rule #1 for me, when see extern C/C++ type/function - always add zero initializer for float/float arrays.

Very few libraries handle nans correctly from my limited experience.

On Monday, 29 April 2024 at 10:15:46 UTC, evilrat wrote:

If you live in a world where no one checks for NaN at any point at any time and/or where a default zero will never hide an error then yep, you're gonna dislike NaN init.

On Monday, 29 April 2024 at 08:12:22 UTC, Monkyyy wrote:

OK, so "silent" here means that the function you invoked did not report the error rather than that the error went undetected (and that the fix is simple if annoying to the "never NaN" contingent).

On Monday, 29 April 2024 at 12:04:00 UTC, Bruce Carneal wrote:

So, if you live in the current world you should dislike nan?

A little convoluted but I'll accept it your surrender

On Monday, 29 April 2024 at 13:29:40 UTC, Monkyyy wrote:

If that's the extent of your "world", yes.

Useful discussion is more about understanding than win/lose. My understanding of the pros and cons of NaN initialization has not changed.

On Monday, 29 April 2024 at 13:29:40 UTC, Monkyyy wrote:

Programming is a big world.

For the things I do, nan works well. I've had to point out many times here and elsewhere that 0 is a great default if you're going to calculate a sum. If you're taking a product, it's an absolute disaster, and it's hard to detect unless you end up with something like a division by zero. At least nan doesn't work its way through the system silently, and it's easy to test for errors, unlike the case of 0.

If nan is a problem, then double x; shouldn't compile. Setting x to 0 is no better for correctness than setting it to a random number. Either way, you're pretending the compiler knows what it should be, and that's impossible.

On Monday, 29 April 2024 at 14:17:41 UTC, Bruce Carneal wrote:

despite being in a thread of 4 people saying "yes nan init is a huge annoyance [specif use case and terrible work arounds]"?

On Monday, 29 April 2024 at 14:58:00 UTC, bachmeier wrote:

trade offs and downsides do not imply relativism

"different countrys use different drinking ages, lol laws have no right answers, better legalize cannibalism"

0 is correct for sum, 1 is correct for products, random numbers are even ok; yes so there tradeoffs between any of these; but nan is a black hole specifically designed to break everything

For real time systems the end up making calls to gpus that do nothing with nans; all floating point math will have 1000's of math operations that will probably never have a type error or a crash where partial solutions such damping math break only for nans.

On Monday, 29 April 2024 at 17:40:54 UTC, monkyyy wrote:

If this is so annoying...

double x = 0;

why not

struct MyDouble
{
    double x = 0;
    alias this = x;
}

On Monday, 29 April 2024 at 17:40:54 UTC, monkyyy wrote:

Yes. As is apparent in this and any other NaN init discussion that I've been part of, there are pros and cons that people weigh differently. The weight I place on being able to more readily isolate potentially difficult FP bugs is higher than the weight I place on the auto-zero benefits combined.

I can and have worked without NaN init. The world didn't end nor did I call for a NaN init crusade, but I prefer NaN init to zero init and either to undefined init.