4 ms·
This is of course how it is supposed to work. It is useful to define NaN this way, as a simple test for NaN is (num == num) returning false. While we're on the
by simonsarris 15y ago
This is of course how it is supposed to work. It is useful to define NaN this way, as a simple test for NaN is (num == num) returning false.
While we're on the topic of NaN, I'd like to mention a lesson from my little book of JavaScript you should never do[1]: You should never use null in JavaScript for the value of a yet-to-determine number. Always use NaN.
Why? It will be easier to detect problems:
var determineLater = NaN;
var blah = 5;
blah += determineLater;
blah is now NaN because (5 + NaN) is NaN. We want this because we want to know if there's been some kind of error in the making of blah
Better:
var determineLater = null;
var blah = 5;
blah += determineLater;
blah is now 5 because (5 + null) is 5. We do not want this because it doesn't let us know that there's been an error (the error typically being that determineLater was - incorrectly - never determined!)
[1] not a real book, just a text file of mis-use cases.
- masklinn 15y agoYou know what's a simple test for NaN? The isNaN built-in function...
- simonsarris 15y agoYes, but this is bigger than that. JavaScript doesn't define NaN, IEEE-754 defines NaN and JavaScript takes its definition from that. So it's IEEE-754 thinks num == num being false is a good test for NaN. For the record, isNaN in JavaScript is also not necessarily the fastest way of doing it: http://jsperf.com/nantest http://jsperf.com/nantest
- masklinn 15y ago> For the record, isNaN in JavaScript is also not necessarily the fastest way of doing it Which will absolutely not matter in 100% of the cases after rounding. `isNaN` is simple (your original criteria) and clearly says what it's doing.
- teaspoon 15y agoblah is now NaN because (5 + NaN) is NaN. We want this because we want to know if there's been some kind of error in the making of blah Commence countdown to frontpage submission "Float is a monad". I agree with your justification for 5 + NaN evaluating to NaN, but it would be even more useful if NaN == x (and every other operation on NaN) would evaluate to NaN as well. That's obviously not possible in statically typed languages, but it is in JS.
- sid0 15y agoHaha, "float is a monad" is the first thing that popped into my head when I read that.
- brendoncrawford 15y ago> You should never use null in JavaScript for the value of a yet-to-determine number. Always use NaN. Actually, it is more idiomatic to use undefined for this purpose rather than NaN... var determineLater; // undefined var blah = 5; blah += determineLater; // blah is now NaN
- grandpa 15y agoIt's things like this that make it hard to write optimizers where floating point is used. Many algebraic identities just don't apply: x == x can't be reduced to true, 0-x isn't the same as -x (it fails for +0), x<=y isn't the opposite of x>y (because of NaN), (a+b)+c isn't the same as a+(b+c), and you can't replace ac+bc with a*(b+c). The paper "What Every Computer Scientist Should Know About Floating Point Arithmetic" is a good guide to the details.