Jump to page: 1 221  
Page
Thread overview
Movement against float.init being nan
Aug 19, 2022
Hipreme
Aug 19, 2022
bachmeier
Aug 19, 2022
IGotD-
Aug 19, 2022
Adam D Ruppe
Aug 19, 2022
Basile B.
Aug 19, 2022
rikki cattermole
Aug 19, 2022
bachmeier
Aug 20, 2022
Walter Bright
Aug 20, 2022
Walter Bright
Aug 20, 2022
Hipreme
Aug 21, 2022
Walter Bright
Aug 21, 2022
Walter Bright
Aug 21, 2022
claptrap
Aug 21, 2022
Walter Bright
Aug 21, 2022
claptrap
Aug 21, 2022
Dark Hole
Aug 21, 2022
Paul Backus
Aug 21, 2022
Dark Hole
Oct 09, 2023
Timon Gehr
Oct 09, 2023
monkyyy
Aug 21, 2022
drug007
Aug 21, 2022
Walter Bright
Aug 21, 2022
Mike Parker
Aug 21, 2022
jordan4ibanez
Aug 21, 2022
Walter Bright
Aug 21, 2022
IGotD-
Aug 21, 2022
claptrap
Aug 20, 2022
Dukc
Aug 20, 2022
Nick Treleaven
Aug 20, 2022
Adam D Ruppe
Aug 20, 2022
Nick Treleaven
Aug 20, 2022
Adam D Ruppe
Aug 20, 2022
Nick Treleaven
Aug 20, 2022
Adam D Ruppe
Aug 20, 2022
IGotD-
Aug 20, 2022
Paul Backus
Aug 20, 2022
Nick Treleaven
Aug 21, 2022
Walter Bright
Aug 21, 2022
Ali Çehreli
Aug 21, 2022
Walter Bright
Oct 08, 2023
mw
Oct 26, 2023
Walter Bright
Aug 22, 2022
Bastiaan Veelo
Aug 22, 2022
jmh530
Aug 25, 2022
Bastiaan Veelo
Aug 25, 2022
max haughton
Aug 25, 2022
Bastiaan Veelo
Aug 25, 2022
Ali Çehreli
Aug 25, 2022
Paul Backus
Aug 28, 2022
Walter Bright
Aug 30, 2022
Guillaume Piolat
Aug 30, 2022
rikki cattermole
Aug 30, 2022
Guillaume Piolat
Aug 20, 2022
Dom Disc
Aug 20, 2022
Paul Backus
Aug 20, 2022
mw
Aug 20, 2022
rikki cattermole
Aug 20, 2022
Paul Backus
Aug 20, 2022
Dom Disc
Aug 21, 2022
Walter Bright
Aug 21, 2022
Dom Disc
Aug 25, 2022
Walter Bright
Aug 20, 2022
kdevel
Aug 19, 2022
claptrap
Aug 20, 2022
zjh
Aug 20, 2022
Walter Bright
Aug 25, 2022
Walter Bright
Aug 20, 2022
Nick Treleaven
Aug 19, 2022
Hipreme
Aug 19, 2022
Basile B.
Aug 20, 2022
Max Samukha
Aug 20, 2022
Walter Bright
Aug 20, 2022
Ali Çehreli
Aug 20, 2022
Tejas
Aug 20, 2022
Salih Dincer
Aug 20, 2022
Max Samukha
Aug 20, 2022
Max Samukha
Aug 20, 2022
Bastiaan Veelo
Aug 20, 2022
Ali Çehreli
Aug 22, 2022
Salih Dincer
Aug 22, 2022
novice2
Aug 20, 2022
Dukc
Aug 23, 2022
Walter Bright
Aug 23, 2022
jordan4ibanez
Aug 23, 2022
jordan4ibanez
Aug 23, 2022
jordan4ibanez
Aug 23, 2022
bauss
Aug 23, 2022
IGotD-
Aug 23, 2022
Ali Çehreli
Aug 23, 2022
IGotD-
Aug 24, 2022
Walter Bright
Aug 23, 2022
claptrap
Aug 23, 2022
Tejas
Aug 24, 2022
Walter Bright
Aug 24, 2022
Paul Backus
Aug 24, 2022
Walter Bright
Aug 23, 2022
Zoadian
Aug 23, 2022
jmh530
Aug 20, 2022
jordan4ibanez
Aug 21, 2022
Walter Bright
Aug 21, 2022
claptrap
Aug 21, 2022
drug007
Aug 21, 2022
apz28
Aug 21, 2022
IGotD-
Aug 21, 2022
drug007
Aug 22, 2022
Dom Disc
Aug 22, 2022
claptrap
Aug 22, 2022
drug007
Aug 22, 2022
claptrap
Aug 23, 2022
drug007
Aug 22, 2022
Dom Disc
Aug 22, 2022
claptrap
Aug 22, 2022
zjh
Aug 22, 2022
wjoe
Aug 23, 2022
Walter Bright
Aug 25, 2022
Walter Bright
Aug 27, 2022
Nick Treleaven
Aug 22, 2022
drug007
Aug 22, 2022
drug007
Aug 23, 2022
Ali Çehreli
Aug 23, 2022
wjoe
Aug 24, 2022
Walter Bright
Aug 24, 2022
ryuukk_
Aug 24, 2022
ryuukk_
Aug 24, 2022
ryuukk_
Aug 24, 2022
user1234
Aug 25, 2022
Walter Bright
Aug 25, 2022
Walter Bright
Aug 22, 2022
Guillaume Piolat
Aug 23, 2022
Dave P.
Aug 23, 2022
Ali Çehreli
Aug 23, 2022
Dave P.
Aug 23, 2022
Ali Çehreli
Aug 23, 2022
Paul Backus
Aug 24, 2022
Walter Bright
Aug 23, 2022
Walter Bright
Aug 24, 2022
Walter Bright
Aug 25, 2022
Walter Bright
Aug 25, 2022
Adam D Ruppe
Aug 25, 2022
Walter Bright
Aug 25, 2022
Adam D Ruppe
Aug 26, 2022
Walter Bright
Aug 25, 2022
zjh
Aug 25, 2022
bauss
Aug 25, 2022
user1234
Aug 25, 2022
bauss
Aug 25, 2022
max haughton
Aug 25, 2022
Paul Backus
Aug 25, 2022
Paul Backus
Aug 25, 2022
IGotD-
Aug 25, 2022
Walter Bright
Aug 30, 2022
Timon Gehr
Aug 30, 2022
Walter Bright
Aug 31, 2022
Timon Gehr
Aug 31, 2022
Adam D Ruppe
Aug 31, 2022
H. S. Teoh
Aug 25, 2022
user1234
Aug 25, 2022
Walter Bright
Aug 25, 2022
kdevel
Aug 26, 2022
Walter Bright
Aug 26, 2022
Walter Bright
Aug 26, 2022
Ali Çehreli
Aug 26, 2022
IGotD-
Aug 27, 2022
Paulo Pinto
Aug 30, 2022
Timon Gehr
Aug 30, 2022
Tejas
Aug 30, 2022
Adam D Ruppe
Aug 30, 2022
wjoe
Aug 30, 2022
Adam D Ruppe
Aug 30, 2022
wjoe
Aug 30, 2022
bauss
Aug 30, 2022
Walter Bright
Aug 30, 2022
Adam D Ruppe
Aug 30, 2022
Salih Dincer
Aug 30, 2022
Walter Bright
Aug 31, 2022
Timon Gehr
Aug 30, 2022
H. S. Teoh
Oct 12, 2023
cc
Oct 26, 2023
Witold
Oct 26, 2023
mw
Aug 26, 2022
apz28
Aug 26, 2022
Dukc
Aug 26, 2022
ryuukk_
Aug 26, 2022
bauss
Aug 26, 2022
Walter Bright
Aug 26, 2022
IGotD-
Aug 30, 2022
Walter Bright
Aug 30, 2022
jmh530
August 19, 2022

As someone coming from Java to use D, I find it myself quite annoying that float and double are initialized to nan.

This is really bad, it is hard to detect for newcomers, there is no flag by default to throw an exception when some operation on nan is done. It can be misleading if you're not paying a lot of attention to what you're doing.

What I suggest is what any sane people would: use 0 as the start for float and double. 0 is the most common sense as a starting point for everything, and, there are 2 options we could go:

1: Emit a compilation error that every variable must be initialized (I thought D were trying to avoid runtime errors)
2: 0 init all types, so, none is actually invalid before use

Even char took me as surprise to know it actually starts as 0xff, I lost a bit of time trying to find that bug because it is so common that variables init as zero.

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.

August 19, 2022

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

>

What I suggest is what any sane people would: use 0 as the start for float and double. 0 is the most common sense as a starting point for everything, and, there are 2 options we could go:

That would be a disaster. If you're computing a product, 0 is horrible, and there's nothing to suggest you're doing something wrong. At least nan is going to tell you that you've screwed up. The reasonable fix is to either make it a compilation error (my preference) or an error when compiled with a particular flag.

August 19, 2022

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

>

This is really bad, it is hard to detect for newcomers, there is no flag by default to throw an exception when some operation on nan is done. It can be misleading if you're not paying a lot of attention to what you're doing.

Question: Can the x86 be set to trap when an operation with NaN is detected?

August 19, 2022
On Friday, 19 August 2022 at 13:58:28 UTC, IGotD- wrote:
> Question: Can the x86 be set to trap when an operation with NaN is detected?

Yes, that's called the signaling nan. D actually used to use that for init and it was changed a few years ago:

https://forum.dlang.org/thread/nsp1ql$ivu$1@digitalmars.com
August 19, 2022

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

>

As someone coming from Java to use D, I find it myself quite annoying that float and double are initialized to nan.

This is really bad, it is hard to detect for newcomers, there is no flag by default to throw an exception when some operation on nan is done. It can be misleading if you're not paying a lot of attention to what you're doing.

What I suggest is what any sane people would: use 0 as the start for float and double. 0 is the most common sense as a starting point for everything, and, there are 2 options we could go:

1: Emit a compilation error that every variable must be initialized (I thought D were trying to avoid runtime errors)
2: 0 init all types, so, none is actually invalid before use

Even char took me as surprise to know it actually starts as 0xff, I lost a bit of time trying to find that bug because it is so common that variables init as zero.

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.

It's not a mistake, default initialization in D is not designed to be an initialization substitute, it's designed in a way that missing initialization is easily detectable but not UB. However, thruth is that this only works for character and floating point types.

Changing that design would require a DIP I think.

August 19, 2022

On 8/19/22 12:34 PM, Basile B. wrote:

>

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

>

As someone coming from Java to use D, I find it myself quite annoying that float and double are initialized to nan.

This is really bad, it is hard to detect for newcomers, there is no flag by default to throw an exception when some operation on nan is done. It can be misleading if you're not paying a lot of attention to what you're doing.

What I suggest is what any sane people would: use 0 as the start for float and double. 0 is the most common sense as a starting point for everything, and, there are 2 options we could go:

1: Emit a compilation error that every variable must be initialized (I thought D were trying to avoid runtime errors)
2: 0 init all types, so, none is actually invalid before use

Even char took me as surprise to know it actually starts as 0xff, I lost a bit of time trying to find that bug because it is so common that variables init as zero.

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.

It's not a mistake, default initialization in D is not designed to be an initialization substitute, it's designed in a way that missing initialization is easily detectable but not UB. However, thruth is that this only works for character and floating point types.

Changing that design would require a DIP I think.

This is true, it's not a mistake, it is on purpose. The original idea behind default values is to correct so many mistakes from C where values are not initialized but just "happen" to work until it doesn't. But practically, it is now used as de-facto initialization, it's just too convenient. In that mindset, floats defaulting to NaN are an outlier.

However, in my recent efforts to port a decently sized C library to D, one thing I don't have a good answer for is code like:

ReallyLargeStruct foo = { 0 };

There just is no equivalent in D. In order to set all fields to 0, I would have to specify a complete layout of the entire thing. This could probably be done via introspection. But I just don't like it even in that case.

The easier thing to do is to default the float and double fields to 0 in the type definition, and then use default initialization to achieve the same. So I think in some cases, it's much nicer to just rely on the default initialization.

I also would prefer that all floats/doubles default to 0 instead of NaN.

-Steve

August 20, 2022
Shame its not as simple as writing:

foo.tupleof = 0;
August 19, 2022

On Friday, 19 August 2022 at 17:14:35 UTC, Steven Schveighoffer wrote:

>

I also would prefer that all floats/doubles default to 0 instead of NaN.

It would be awful to choose an arbitrary, often incorrect value in order to give the appearance that your program is running.

It would be absurd to silently set the value of z to 1.0 in this code:

double w;
double z = w*2.5 + 1;

Defaulting to 0 is no better than defaulting to a random number.

August 19, 2022

On Friday, 19 August 2022 at 16:34:59 UTC, Basile B. wrote:

>

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

>

As someone coming from Java to use D, I find it myself quite annoying that float and double are initialized to nan.

This is really bad, it is hard to detect for newcomers, there is no flag by default to throw an exception when some operation on nan is done. It can be misleading if you're not paying a lot of attention to what you're doing.

What I suggest is what any sane people would: use 0 as the start for float and double. 0 is the most common sense as a starting point for everything, and, there are 2 options we could go:

1: Emit a compilation error that every variable must be initialized (I thought D were trying to avoid runtime errors)
2: 0 init all types, so, none is actually invalid before use

Even char took me as surprise to know it actually starts as 0xff, I lost a bit of time trying to find that bug because it is so common that variables init as zero.

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.

It's not a mistake, default initialization in D is not designed to be an initialization substitute, it's designed in a way that missing initialization is easily detectable but not UB. However, thruth is that this only works for character and floating point types.

Changing that design would require a DIP I think.

Well, it is used as initialization substitute, if wasn't meant to be a substitute, not initializing a variable should be a compilation error. There's a lot of developers which uses bool and int because they make sense, when dealing with floating point they forget about that they do not make sense. I've never had any problem with float defaulting to 0 on Java. If the error happens, I get at max division by 0 exception. NaN does not cause this exception which actually makes the bug harder to find.

August 19, 2022

On 8/19/22 2:04 PM, bachmeier wrote:

>

On Friday, 19 August 2022 at 17:14:35 UTC, Steven Schveighoffer wrote:

>

I also would prefer that all floats/doubles default to 0 instead of NaN.

It would be awful to choose an arbitrary, often incorrect value in order to give the appearance that your program is running.

The problem is that most people declare a number like int x and expect it to default to 0. Because that's what D does.

For a float (number), they expect the same thing.

But it defaults to a completely useless value (NaN). This is unexpected, and commonly leads to hours of head-scratching (see Adam's Ruppe's 2020 live coding session, where he couldn't figure out for much of the stream why his game wasn't working).

>

It would be absurd to silently set the value of z to 1.0 in this code:

double w;
double z = w*2.5 + 1;

Not absurd at all. if w defaults to 0, I would expect z to be 2.5 * 0 + 1.

Change it to int, and see if it looks absurd to you. You just aren't used to it.

D used default values to prevent errors in not initializing values, but default initialization to a very commonly-expected value turns to be incredibly useful.

The design choices for float/double were made based on the fact that a value that means "this isn't initialized" existed. It didn't for int, so meh, 0 was chosen. Walter could have easily have just chosen int.min or something, and then we would possibly not ever be used to it. But now we are used to it, so it has become irksome that doubles/floats are the outlier here.

-Steve

« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11