Movement against float.init being nan (page 5)

> By the way, you don't have to write this yourself; you can use Checked!(int, WithNaN) [1] from std.checkedint. > > [1] https://phobos.dpldocs.info/std.checkedint.WithNaN.html BTW, where to report Dlang website (doc) bug? https://dlang.org/phobos/std_experimental_checkedint.html This module is now deprecated, use std.experimental instead. <== should be std.checkedint The link is also wrong: https://dlang.org/phobos/std_experimental.html Oh No! Page Not Found

On Saturday, 20 August 2022 at 21:38:13 UTC, mw wrote: > BTW, where to report Dlang website (doc) bug? > > https://dlang.org/phobos/std_experimental_checkedint.html > > This module is now deprecated, use std.experimental instead. <== should be std.checkedint > > The link is also wrong: > > https://dlang.org/phobos/std_experimental.html > > Oh No! Page Not Found Report it on issues.dlang.org as a bug in dlang.org.

On 8/20/22 14:07, Bastiaan Veelo wrote: > alias Distance = Typedef!(double, 0.0, "distance"); Great! :) > However, type information can get lost in intermediate results: > ```d > t = 0.5 + d; // result is double > ``` Yeah, that's a bummer. Perhaps something like this could work: "have all the functionality of a double but don't implicitly convert to one." (Ironically, alias this is the implicit conversion tool.) And what do I mean? Only when being passed to a function? I don't know... :/ Ali

August 20, 2022

Re: Movement against float.init being nan

Posted by Dukc
in reply to Hipreme

Permalink

Dukc

Posted in reply to Hipreme

Permalink

On Friday, 19 August 2022 at 13:42:58 UTC, Hipreme wrote:

Although the char is a bit different beast in terms of breaking change, I really can't see anyone actually depending that your float is being initialized with nan, so I really would like to know how much people agree with this idea. It is so common to stumble on that problem that it is starting to feel as a real mistake.

I personally like how D does it. Once you know that floats have a "nothing" value, it's very convenient that it's the initialisation value, for the same reason null is a convenient initialisation value for pointers and class references. But I can see that if I didn't know about NaNs, this would be annoying. The big weakness is that it goes against what C, C++ and C# (and probably many other languages) do so one is easily surprised.

However, the big philosophy behind it is that D always uses an "empty" value as the initialisation value if there is one, so for D this is the right thing to do. Using 0 as float .init would be inconsistent with rest of the language. Whether this underlying philosophy is a good idea is debatable though. Personally I think the philosophy has it's ups and downs but easy to like once you get used to it.

On Saturday, 20 August 2022 at 18:47:29 UTC, Paul Backus wrote: > On Saturday, 20 August 2022 at 18:05:59 UTC, Dom Disc wrote: >> 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. > > By the way, you don't have to write this yourself; you can use Checked!(int, WithNaN) [1] from std.checkedint. > > [1] https://phobos.dpldocs.info/std.checkedint.WithNaN.html I know. I like my implementation better, but that's not the point. My point is: I include this in EVERY of my programs and never use other signed integers (unsigned values I use for bit-manipulation, not for calculations). checkedint should simply BE the int type, not a module.

We could make it the worst of both worlds. We could have it so sometimes an unitialized float or double is NaN and make it be the garbage data that was the memory address depending on if a random number is below 0.5 or not.

I'm kidding.

I would actually prefer it to throw an error if you did not initialize a variable. :) This would make programming more explicit upfront but prevent you from tearing out your hair in a few months where a part of a library you're using suddenly starts throwing weird errors out and you are left with a cup full of tears. This goes for all variables of primitive type to use Java speak. This would not only solve the issue of "OI IT SHOULD BE ZERO!!" and "OI IT SHOULD BE NAN!!!". No way Jose, it should be what you tell it to be because the computer should do what you told it to do when creating those values, not guess. Because it can only tell how you're trying to do it, not what you're trying to do. It's not a soothsayer, it's a glorified calculator.

On 8/20/2022 6:19 AM, Hipreme wrote: > I don't see how easier it is to track a nan. Division by zero causes exception which is the best thing ever. Multiplication produces a zero result, which is pretty obvious to track. If the number does not change you will pretty much print both values and you'll easily find the 0 there. x * NaN => NaN x / NaN => NaN x + NaN => NaN x - NaN => NaN -Nan => NaN cos(NaN) => NaN exp(NaN) => NaN Only a subset of this is true for 0.

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.

Forums