Rendered at 06:43:31 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
WalterBright 8 hours ago [-]
NaNs are a very underappreciated feature of IEEE-754 floating point. In the D programming language, floats get default initialized to NaN, not to 0.0.
double y = 0.0; // initialized to 0.0
double x; // initialized to NaN
The discussion routinely comes up as "why not default initialize to 0.0?" The reason is a routine mistake in programming is forgetting to initialize a variable. With a floating point 0.0, one may never realize that the floating point calculation results are wrong. But with NaN, the result of a floating point computation will be NaN, which is unlikely to go unnoticed.
I don't know of any other programming language with this safety feature.
Also, the D `char` type is initialized to 0xFF, not 0, because Unicode says that 0xFF is an invalid character.
p1necone 8 hours ago [-]
Just requiring explicit assignment before first use feels like the superior approach to automatic initialization, regardless of whether the automatic initialization is with 0 or with NaN.
WalterBright 8 hours ago [-]
That suggestion is often made.
The trouble with it is a bug I've seen often. People will get an error message about an "uninitialized variable". Then they go into "just get the compiler to shut up" mode, amd pick "0" as the initializer. Then, the program compiles and runs, and silently produces the wrong answer. Code reviews will simply pass over the "0" initializer, as it looks right.
With default NaN initialization, the programmer is more likely to stop and think about it, not just insert 0.
For the purposes of code clarity I don't want to see a variable initialized to a value that is never used, just to shut the compiler up.
ncurses1010 5 hours ago [-]
With the default initialization to nan, do you ever run into situations where people are searching for common sources for nan (nan literals, div by zero) and they can't find it? Or cases where only some branches but not others initialize the float?
WalterBright 5 hours ago [-]
To leave a variable uninitialized, use the construction:
int x = void;
Note that nobody is going to write this by accident. And it's easy to grep for.
To find the source of a NaN, it helps to know that every operation that has a NaN as an operand produces a NaN as a result. So if you see a NaN in the output, you can work backwards to where it originated.
ncurses1010 12 minutes ago [-]
What do you think of kotlins approach where it has a 'todo' function that can always coerce to a type, but instead of populating the variable with a default value that's valid, it just throws
jcranmer 4 hours ago [-]
> every operation that has a NaN as an operand produces a NaN as a result.
That's not true. The minimum/maximum functions (fmin and fminimum_num variants, but not the fminimum one) treat NaN inputs as not-present, so return the non-NaN value if there is one. Similarly, hypot also treats NaN inputs as not-present. pow and compoundn will ignore NaN exponents if the base is 1.
WalterBright 4 hours ago [-]
Yes, there are some functions where if one operand has no effect on the result, a NaN value will also have no effect.
billforsternz 3 hours ago [-]
How long did you think about this before making this declaration? How long did Walter Bright think about this before making his decision when designing his language? Not saying you're wrong, just something to think about perhaps.
electroly 3 hours ago [-]
C# requires explicit assignment. If an appeal to authority sways you (it shouldn't), you can substitute Anders Hejlsberg instead of this random OP. How long do you suppose Anders Hejlsberg thought about this?
But I contend it's more useful (and interesting) to think about the idea with your own mind instead of tallying up the perceived authority of its supporters and relying on trust. It was also somewhat rude to suggest that the OP had not given their idea much thought. This is a forum for discussion, isn't it?
WalterBright 52 minutes ago [-]
Unfortunately, what happens with explicit assignment is programmers often enough will:
1. just insert '= 0;' to get it to compile
2. insert '= 0;' and then be puzzled by an initialization further along in the code
3. see the '= 0;' and wonder why the programmer did that as 0 was not a valid value for it
A goal of D is to be able to make code more understandable. Forcing a vacuous initialization on the programmer is not conducive to that.
WalterBright 3 hours ago [-]
Thank you. I've made many counter-intuitive decisions based on long experience. Sometimes I just have to say "trust me".
Like not allowing macros in D, or version algebra.
lmm 5 hours ago [-]
Yep. This is NaN as a billion dollar mistake all over again.
WalterBright 51 minutes ago [-]
Unrecognized subtle errors in floating point calculations are worse problems.
WalterBright 8 hours ago [-]
Another crucial use of NaNs is if you have a sensor. If the sensor has failed, the sensed value should be transmitted as NaN, not 0, so the receiver knows the data is bad.
AlotOfReading 7 hours ago [-]
My experience is that if you write an interface that (rarely) returns NaNs, someone will use it assuming it's never NaN no matter how good the docs are. Then their code does bad things and you have to patiently explain why they're wrong and yes, they are holding isnan() wrong (in C/C++).
WalterBright 6 hours ago [-]
NaN for a failed sensor is objectively better than any other value. But at some point you just cannot help some people.
anitil 8 hours ago [-]
That's a very thoughtful decision, I always enjoy your updates on D
wpollock 8 hours ago [-]
> ... Unicode says that 0xFF is an invalid character.
Not so. You may be thinking of UTF-8 encoding. 0xff is DEL in Unicode.
LittleLily 5 hours ago [-]
DEL is unicode codepoint U+007F, which is the byte 0x7F in UTF-8, not 0xFF.
Perhaps you were thinking of ÿ which is codepoint U+00FF, which encodes to the bytes 0xC3 0xBF in UTF-8.
WalterBright 7 hours ago [-]
The "char" type in D represents a UTF-8 code unit, the byte 0xFF is not a valid character code and is strictly forbidden.
GMoromisato 8 hours ago [-]
I use nan boxing in GridWhale. It feels like the Infinite Hotel[1]: you can always add another type. Note that these techniques also rely on the fact that we don't use all 64-bits for memory addressing. If we ever do, lots of VMs will break.
For me, the major advantage of nan boxing is that you don't have to allocate a whole class of types (like floats). That saves so much at garbage collection time.
This is super useful, thanks. So if I were implementing a programming language, and wanted to have symbols to specify NaN in source code, I'd really only need quiet NaN, right? Because signaling NaN is supposed to always to raise an exception anyway?
WalterBright 6 hours ago [-]
I originally implemented Signalling and Quiet NaNs in the compiler. It was an abject failure. With all the transformations a compiler does, where the signalling turns into a quiet is lost. So just quiet NaNs are used.
I don't know of any other programming language with this safety feature.
Also, the D `char` type is initialized to 0xFF, not 0, because Unicode says that 0xFF is an invalid character.
The trouble with it is a bug I've seen often. People will get an error message about an "uninitialized variable". Then they go into "just get the compiler to shut up" mode, amd pick "0" as the initializer. Then, the program compiles and runs, and silently produces the wrong answer. Code reviews will simply pass over the "0" initializer, as it looks right.
With default NaN initialization, the programmer is more likely to stop and think about it, not just insert 0.
Another issue with it is:
For the purposes of code clarity I don't want to see a variable initialized to a value that is never used, just to shut the compiler up.To find the source of a NaN, it helps to know that every operation that has a NaN as an operand produces a NaN as a result. So if you see a NaN in the output, you can work backwards to where it originated.
That's not true. The minimum/maximum functions (fmin and fminimum_num variants, but not the fminimum one) treat NaN inputs as not-present, so return the non-NaN value if there is one. Similarly, hypot also treats NaN inputs as not-present. pow and compoundn will ignore NaN exponents if the base is 1.
But I contend it's more useful (and interesting) to think about the idea with your own mind instead of tallying up the perceived authority of its supporters and relying on trust. It was also somewhat rude to suggest that the OP had not given their idea much thought. This is a forum for discussion, isn't it?
1. just insert '= 0;' to get it to compile
2. insert '= 0;' and then be puzzled by an initialization further along in the code
3. see the '= 0;' and wonder why the programmer did that as 0 was not a valid value for it
A goal of D is to be able to make code more understandable. Forcing a vacuous initialization on the programmer is not conducive to that.
Like not allowing macros in D, or version algebra.
Not so. You may be thinking of UTF-8 encoding. 0xff is DEL in Unicode.
For me, the major advantage of nan boxing is that you don't have to allocate a whole class of types (like floats). That saves so much at garbage collection time.
------------
[1] https://en.wikipedia.org/wiki/Hilbert%27s_paradox_of_the_Gra...