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.
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.
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 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.
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++).
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?
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.
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.
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.
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.
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.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.
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++).
That's a very thoughtful decision, I always enjoy your updates on D
> ... Unicode says that 0xFF is an invalid character.
Not so. You may be thinking of UTF-8 encoding. 0xff is DEL in Unicode.
The "char" type in D represents a UTF-8 code unit, the byte 0xFF is not a valid character code and is strictly forbidden.
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.
------------
[1] https://en.wikipedia.org/wiki/Hilbert%27s_paradox_of_the_Gra...
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?