I forgot to add that 0.0 is such a common floating point value, its erroneous use cannot be reliably distinguished from valid uses. Just finding a 0 is not good enough, but finding a NaN is.

On 8/20/2022 4:51 AM, Adam D Ruppe wrote:
> That works for float.init specifically, but if you've done some operation on it and ended up with a nan, that will not necessarily be true since nans come in several bit patterns.

I.e. a "payload" can be put in the mantissa bits of a NaN, which can be used to provide more information about the NaN. I've never seen anyone use this, though, but someone might, so isNaN() is the robust approach.

On 8/20/2022 11:05 AM, Dom Disc wrote:
> On Saturday, 20 August 2022 at 01:01:07 UTC, Walter Bright wrote:
>> If there was a NaN value for int, I would have used it as the default. int.min is not really a NaN.
> 
> But it should be!
> int.min is a notorious bogus value. You can't even use abs() on it: it will either give you a different type or return garbage. There is not even a working literal for it (at least for long.min). So it should never have been a valid value from beginning.
> The first thing I include in every of my programs is a module that define exactly that: an alias to byte/short/int/long that takes T.min as invalid value (and uses it as default value) and gives T.min+1 as its real min value.

As soon as an operation is done on it, it isn't int.min anymore. It has some characteristics of a NaN, but not enough.

On 8/20/22 20:44, Walter Bright wrote:

> I.e. a "payload" can be put in the mantissa bits of a NaN, which can be
> used to provide more information about the NaN.

I think it is called "nan boxing."

> I've never seen anyone
> use this, though, but someone might

I heard about it either at a meetup or at a DConf. The speaker was explaining that exact technique.

Ali

On Sunday, 21 August 2022 at 03:26:55 UTC, Walter Bright wrote:
> On 8/20/2022 6:19 AM, Hipreme wrote:
>> Drawing with float is required a lot on modern drawing API.
>
> I find this surprising. My experience with floating point coordinates is you can never quite get the pixels aligned, due to rounding problems.

Graphics APIs have been using floating point for decades now. GPUs are optimized for it. You'll still see 2D APIs around now and again with an integer-based public API, but internally they're sending floats to the GPU.

On Sunday, 21 August 2022 at 03:46:13 UTC, Walter Bright wrote:
> On 8/20/2022 11:05 AM, Dom Disc wrote:
> > that define exactly that: an alias to byte/short/int/long that takes T.min as invalid value (and uses it as default value) and gives T.min+1 as its real min value.
>
> As soon as an operation is done on it, it isn't int.min anymore. It has some characteristics of a NaN, but not enough.

It's no problem to implement saveint so, that int.min stays at that value for all operations (except direct assignment). Ok, as library this may cost a little performance, but I think it's worth it.

On Sunday, 21 August 2022 at 03:41:55 UTC, Walter Bright wrote:
> I forgot to add that 0.0 is such a common floating point value, its erroneous use cannot be reliably distinguished from valid uses. Just finding a 0 is not good enough, but finding a NaN is.

This is a complete misrepresentation. It's not that you find 0s and say oh well it shouldn't be zero here. It's that your results are wrong, stuff on screen isn't where it should be, your data plots are off, it's not doing what it should be etc..

If you're doing some numerical computation and you cant tell when the results are wrong then you almost always doing you're doing something wrong anyway.

The point is, at least in my experience, and I do a lot of DSP and statistics stuff, you know the result is wrong and you just chase it backwards, its the same process whether it's a NaN or just a wrong result.

And the fact is if you'd just disallowed default initialisation it would have caught this bug every time for me, and I wouldn't have just stuck zero in, because the bug is that I forgot to set the value, not that I didn't know what it was.

So from my experience the rational is based on two fallacies.

1. That using zero as default init would hide the bug.
2. That people will just stick zero in because they don't know what it should be.

On Sunday, 21 August 2022 at 03:26:55 UTC, Walter Bright wrote:
>
> I find this surprising. My experience with floating point coordinates is you can never quite get the pixels aligned, due to rounding problems.

That's the whole point. In graphics and especially 3D graphics use floating point in order to achieve sub pixel accuracy. That means it uses the fractional part to draw more accurate lines for example. It can be used for anti antialiasing calculations and so on. Without subpixel accuracy we would experience more "steppy" movement in 3D games for example. This can be observed in early 3D games which only used integer calculations.

On Sunday, 21 August 2022 at 03:26:55 UTC, Walter Bright wrote:
> On 8/20/2022 6:19 AM, Hipreme wrote:
>> Drawing with float is required a lot on modern drawing API.
>
> I find this surprising. My experience with floating point coordinates is you can never quite get the pixels aligned, due to rounding problems.

Modern drawing APIs have sub pixel positioning & antialising. GDI+ had that, at that was XP i think, so what 20 years ago maybe?