www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Floating point types default to NaN?

reply A Guy With a Question <aguywithaquestion gmail.com> writes:
I would have expected 0 to be the default value. What's the logic 
behind having them being NaN by default?

https://dlang.org/spec/type.html
Nov 24
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 24 November 2017 at 14:30:44 UTC, A Guy With a 
Question wrote:
 I would have expected 0 to be the default value. What's the 
 logic behind having them being NaN by default?
It gives you a runtime error (sort of) if you use an uninitialized variable. You ARE supposed to explicitly initialize variables to your own values in D. The automatic init is to make errors stand out more consistently if you don't do this as opposed to being random. So pointers are initialized to null - an invalid value that stands out if you try to use it. chars get \xFF - again, invalid that will throw if you try to utf decode it. Floats get NaN which is as close to invalid as they get. ints happen to get 0 not to be convenient, but because there is no clearly-invalid int value so something had to be chosen, and 0 was just easy to implement....
Nov 24
parent reply A Guy With a Question <aguywithaquestion gmail.com> writes:
On Friday, 24 November 2017 at 14:43:24 UTC, Adam D. Ruppe wrote:
 On Friday, 24 November 2017 at 14:30:44 UTC, A Guy With a 
 Question wrote:
 I would have expected 0 to be the default value. What's the 
 logic behind having them being NaN by default?
It gives you a runtime error (sort of) if you use an uninitialized variable. You ARE supposed to explicitly initialize variables to your own values in D. The automatic init is to make errors stand out more consistently if you don't do this as opposed to being random. So pointers are initialized to null - an invalid value that stands out if you try to use it. chars get \xFF - again, invalid that will throw if you try to utf decode it. Floats get NaN which is as close to invalid as they get. ints happen to get 0 not to be convenient, but because there is no clearly-invalid int value so something had to be chosen, and 0 was just easy to implement....
If thats the case why not just throw a compiler error? D has a way explicitly not set it right? Through void...So if the intent is to find erroneous code right away, just throw a compiler error no?
Nov 24
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, November 24, 2017 20:43:14 A Guy With a Question via Digitalmars-
d-learn wrote:
 On Friday, 24 November 2017 at 14:43:24 UTC, Adam D. Ruppe wrote:
 On Friday, 24 November 2017 at 14:30:44 UTC, A Guy With a

 Question wrote:
 I would have expected 0 to be the default value. What's the
 logic behind having them being NaN by default?
It gives you a runtime error (sort of) if you use an uninitialized variable. You ARE supposed to explicitly initialize variables to your own values in D. The automatic init is to make errors stand out more consistently if you don't do this as opposed to being random. So pointers are initialized to null - an invalid value that stands out if you try to use it. chars get \xFF - again, invalid that will throw if you try to utf decode it. Floats get NaN which is as close to invalid as they get. ints happen to get 0 not to be convenient, but because there is no clearly-invalid int value so something had to be chosen, and 0 was just easy to implement....
If thats the case why not just throw a compiler error? D has a way explicitly not set it right? Through void...So if the intent is to find erroneous code right away, just throw a compiler error no?
That requires data flow analysis, which the compiler doesn't do a lot of, because it can be complicated. It also tends to result in the compiler giving warnings or errors in cases where it's not actually true that the variable is used before it's given a value, because it can't do it perfectly. There was a recent discussion on this in the main newsgroup with regards to guaranteeing with a pointer or reference was initialized to something other than null. Also, when you start having stuff like arrays, having a default initializer is a big boon, since then all of the elements have a default value. It's going to work even worse to try and have the compiler detect when you've properly initialized every element in an array than have it detect when you've properly initialized just a variable. And stuff like the out attribute relies on there being a default initializer. Just all around, having default initializers for types in general makes things cleaner and less error-prone. And NaN math is something that's built into CPU. Operations other than default initialization can result in a floating point value being NaN. So, if you're looking to have NaN not be a thing for floating point values, then you're out of luck. And Walter is a big fan of NaN being a thing, since when you hit it, you know that you've found a bug, and tracking it down tends to be fairly straightforward, which is not the case with many other types of bugs. - Jonathan M Davis
Nov 24
next sibling parent reply Dave Jones <dave jones.com> writes:
On Friday, 24 November 2017 at 22:38:49 UTC, Jonathan M Davis 
wrote:
 On Friday, November 24, 2017 20:43:14 A Guy With a Question via 
 Digitalmars- d-learn wrote:
 On Friday, 24 November 2017 at 14:43:24 UTC, Adam D. Ruppe
That requires data flow analysis, which the compiler doesn't do a lot of, because it can be complicated. It also tends to result in the compiler giving warnings or errors in cases where it's not actually true that the variable is used before it's given a value, because it can't do it perfectly. There was a recent discussion on this in the main newsgroup with regards to guaranteeing with a pointer or reference was initialized to something other than null.
I think he means just spew an error if a float is declared but not explicitly initialised... Whats the problem with... float foo; // compiler error "floats must be explicitly initialised" float foo = float.nan; // old behaviour. I mean at the end of the day, that would turn a run time error into a compile time error which is a good thing isnt it?
Nov 25
next sibling parent reply A Guy With a Question <aguywithaquestion gmail.com> writes:
On Saturday, 25 November 2017 at 09:39:15 UTC, Dave Jones wrote:
 On Friday, 24 November 2017 at 22:38:49 UTC, Jonathan M Davis 
 wrote:
 On Friday, November 24, 2017 20:43:14 A Guy With a Question 
 via Digitalmars- d-learn wrote:
 On Friday, 24 November 2017 at 14:43:24 UTC, Adam D. Ruppe
That requires data flow analysis, which the compiler doesn't do a lot of, because it can be complicated. It also tends to result in the compiler giving warnings or errors in cases where it's not actually true that the variable is used before it's given a value, because it can't do it perfectly. There was a recent discussion on this in the main newsgroup with regards to guaranteeing with a pointer or reference was initialized to something other than null.
I think he means just spew an error if a float is declared but not explicitly initialised... Whats the problem with... float foo; // compiler error "floats must be explicitly initialised" float foo = float.nan; // old behaviour. I mean at the end of the day, that would turn a run time error into a compile time error which is a good thing isnt it?
That is exactly what I meant. I think most languages just choose to default it to something convenient, which is 0. C++ chooses not to default it for speed reasons. If D chooses it's defaults to make errors stick out, why not just error at declaration if they don't explicitly set it to something. Including void, which would give you C++ undefined behavior from what I've read so far.
Nov 25
next sibling parent A Guy With a Question <aguywithaquestion gmail.com> writes:
Nonetheless, my original question was answered. Thanks for the 
insights!
Nov 25
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 25 November 2017 at 16:16:52 UTC, A Guy With a 
Question wrote:
 If D chooses it's defaults to make errors stick out, why not 
 just error at declaration if they don't explicitly set it to 
 something.
It technically did: https://dlang.org/spec/function.html#local-variables "It is an error to use a local variable without first assigning it a value. The implementation may not always be able to detect these cases. Other language compilers sometimes issue a warning for this, but since it is always a bug, it should be an error. " But that paragraph was never implemented (it is a bit easier said than done to actually detect given if conditions and stuff too, especially in the early days of D when the compiler didn't even make any effort to track such things, though it does now...). The compiler author took the easy way out of initializing them to invalid values instead. While it is more realistic to implement technically now than it was years ago when the current behavior got in, I think we're at the point now that so many people use it as a convenience thing on ints and nulls that there'd be hell to pay if the compiler actually started calling it an error :(
Nov 25
next sibling parent A Guy With a Question <aguywithaquestion gmail.com> writes:
On Saturday, 25 November 2017 at 22:13:43 UTC, Adam D. Ruppe 
wrote:
 On Saturday, 25 November 2017 at 16:16:52 UTC, A Guy With a 
 Question wrote:
 If D chooses it's defaults to make errors stick out, why not 
 just error at declaration if they don't explicitly set it to 
 something.
It technically did: https://dlang.org/spec/function.html#local-variables "It is an error to use a local variable without first assigning it a value. The implementation may not always be able to detect these cases. Other language compilers sometimes issue a warning for this, but since it is always a bug, it should be an error. " But that paragraph was never implemented (it is a bit easier said than done to actually detect given if conditions and stuff too, especially in the early days of D when the compiler didn't even make any effort to track such things, though it does now...). The compiler author took the easy way out of initializing them to invalid values instead. While it is more realistic to implement technically now than it was years ago when the current behavior got in, I think we're at the point now that so many people use it as a convenience thing on ints and nulls that there'd be hell to pay if the compiler actually started calling it an error :(
Fair enough!
Nov 25
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/25/17 5:13 PM, Adam D. Ruppe wrote:
 On Saturday, 25 November 2017 at 16:16:52 UTC, A Guy With a Question wrote:
 If D chooses it's defaults to make errors stick out, why not just 
 error at declaration if they don't explicitly set it to something.
It technically did: https://dlang.org/spec/function.html#local-variables "It is an error to use a local variable without first assigning it a value. The implementation may not always be able to detect these cases. Other language compilers sometimes issue a warning for this, but since it is always a bug, it should be an error. " But that paragraph was never implemented (it is a bit easier said than done to actually detect given if conditions and stuff too, especially in the early days of D when the compiler didn't even make any effort to track such things, though it does now...). The compiler author took the easy way out of initializing them to invalid values instead. While it is more realistic to implement technically now than it was years ago when the current behavior got in, I think we're at the point now that so many people use it as a convenience thing on ints and nulls that there'd be hell to pay if the compiler actually started calling it an error :(
I rely on the default value initialization all the time! I don't know how that would jive with structs, since they are technically local variables, but usually are valid without initialization. What about AAs? Would you have to do = []? -Steve
Nov 27
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 27 November 2017 at 14:58:42 UTC, Steven Schveighoffer 
wrote:
 I rely on the default value initialization all the time! I 
 don't know how that would jive with structs, since they are 
 technically local variables, but usually are valid without 
 initialization.
Yes, indeed, me too. I like it now. But there might be a compromise that is still workable: let structs and ints (and bytes, short, etc) be exceptions and not issue an error there. But then conservatively check other types. If the compiler sees any read before any write, issue the error. Otherwise, keep the status quo. That's fit the spec and catch real bugs more often than false positives. Though, I'm in no ruse to see that implemented either, overall I am meh on it.
 What about AAs? Would you have to do = []?
they could be an exception too, but you could do = null (= [] won't pass the type check lol)
Nov 27
prev sibling parent reply Michael V. Franklin <slavo5150 yahoo.com> writes:
On Saturday, 25 November 2017 at 22:13:43 UTC, Adam D. Ruppe 
wrote:

 It technically did:

 https://dlang.org/spec/function.html#local-variables

 "It is an error to use a local variable without first assigning 
 it a value. The implementation may not always be able to detect 
 these cases. Other language compilers sometimes issue a warning 
 for this, but since it is always a bug, it should be an error. "


 But that paragraph was never implemented (it is a bit easier 
 said than done to actually detect given if conditions and stuff 
 too, especially in the early days of D when the compiler didn't 
 even make any effort to track such things, though it does 
 now...). The compiler author took the easy way out of 
 initializing them to invalid values instead.
WOW!! I am shocked to learn this. All this time, I though it was a design oversight. I think I'm going to implement a feature gate to require explicit initialization. It would be better to be strict up front and relax it as flow control analysis becomes more mature. Mike
Nov 27
parent reply Michael V. Franklin <slavo5150 yahoo.com> writes:
On Monday, 27 November 2017 at 23:05:55 UTC, Michael V. Franklin 
wrote:

 I think I'm going to implement a feature gate to require 
 explicit initialization.  It would be better to be strict up 
 front and relax it as flow control analysis becomes more mature.
Well, I implemented it (https://github.com/dlang/dmd/pull/7375), but it's off to a pretty rocky start. Mike
Nov 28
parent reply A Guy With a Question <aguywithanquestion gmail.com> writes:
On Tuesday, 28 November 2017 at 20:00:53 UTC, Michael V. Franklin 
wrote:
 On Monday, 27 November 2017 at 23:05:55 UTC, Michael V. 
 Franklin wrote:

 I think I'm going to implement a feature gate to require 
 explicit initialization.  It would be better to be strict up 
 front and relax it as flow control analysis becomes more 
 mature.
Well, I implemented it (https://github.com/dlang/dmd/pull/7375), but it's off to a pretty rocky start. Mike
To be honest, I didn't actually expect anyone to act on my question. :D I was just more curious of the design decisions that were made.
Nov 28
parent reply Michael V. Franklin <slavo5150 yahoo.com> writes:
On Wednesday, 29 November 2017 at 01:24:21 UTC, A Guy With a 
Question wrote:

 I was just more curious of the design decisions that were made.
So am I. I'm trying to get to the heart of in the the PR comments. Mike
Nov 28
parent A Guy With a Question <aguywithanquestion gmail.com> writes:
On Wednesday, 29 November 2017 at 01:25:47 UTC, Michael V. 
Franklin wrote:
 On Wednesday, 29 November 2017 at 01:24:21 UTC, A Guy With a 
 Question wrote:

 I was just more curious of the design decisions that were made.
So am I. I'm trying to get to the heart of in the the PR comments. Mike
That's a lot less code than I would have thought to implement that. The comment about phobos was a good one. Just reading through it.
Nov 28
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Saturday, 25 November 2017 at 09:39:15 UTC, Dave Jones wrote:
 I mean at the end of the day, that would turn a run time error 
 into a compile time error which is a good thing isnt it?
Debatable in this case. Consider: string servicePhoneNumber; final switch (car.manufacturer) //an enumerated value. { case CarMaker.Audi: servicePhoneNumber = staff["Dorff Hans"].phone; //... break; case CarMaker.Skoda: servicePhoneNumber = staff["Telegin Svetlana"].phone; //... break; //more cases ... } Here it is arguably unnecessary typing if you had to manually set servicePhoneNumber to "" or something at start. And in case of structs it tends to be a verbose thing to manually set one to it's init value.
Nov 27
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 27 November 2017 at 16:04:14 UTC, Dukc wrote:
 Debatable in this case. Consider:

 string servicePhoneNumber;

 final switch (car.manufacturer) //an enumerated value.
Well, the compiler can see it is initialized before being read again later, so that *should* pass the check (at least conservatively- the spec is flexible enough to let the compiler not catch them all).
Nov 27
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 24 November 2017 at 22:38:49 UTC, Jonathan M Davis 
wrote:
 That requires data flow analysis, which the compiler doesn't do 
 a lot of, because it can be complicated.
If dataflow is sufficient then it isn't all that complicated, you can implement generic dataflow using Monotone Frameworks: http://symbolaris.com/course/Compilers11/27-monframework.pdf But on the other hand, data flow might not be sufficient for what you want to do.
 And NaN math is something that's built into CPU. Operations 
 other than default initialization can result in a floating 
 point value being NaN.
If you have turned on exceptions for signalling-NaNs then it makes sense. It doesn't make all that much sense for quiet NaNs.
Nov 25
prev sibling parent codephantom <me noyb.com> writes:
On Friday, 24 November 2017 at 14:30:44 UTC, A Guy With a 
Question wrote:
 I would have expected 0 to be the default value. What's the 
 logic behind having them being NaN by default?

 https://dlang.org/spec/type.html
http://www.drdobbs.com/cpp/nans-just-dont-get-no-respect/240005723
Nov 29