11 ms·
In JavaScript: (!NaN) // true (NaN == false) // false
by ffhhj 5y ago
In JavaScript:
(!NaN) // true
(NaN == false) // false
- dTal 5y agoI think that says more about JavaScript than NaN. Also JavaScript: "10"+1 => "101" "10"-1 => 9
- mlindner 5y agoThe hell?
- varanauskas 5y agoString addition = concatenation String subtraction = ??? => Number subtraction
- david_allison 5y agotypeof(NaN) // 'number'
- dylan604 5y agoyes. it is nota number. the result of taking the square root of a negative result from dividing by zero.
- nawgz 5y agoIs this interesting? It's true for undefined, null, empty string, 0, maybe empty arrays sometimes, ...
- nayuki 5y agoYes, what you presented are WTFs. But the biggest WTF is that in every language, NaN == NaN yields false.
- dTal 5y agoThat makes perfect sense. Why should two NaNs compare equal? NaN is Not A Number - it means "you messed up and did an invalid calculation". You can't do equality comparisons on that.
- mikepurvis 5y agoYeah, and even in the basic case of infinities/limits, it's pretty obvious that they're not equal. Otherwise you could make any equation work by dividing both sides by zero.
- lmm 5y agoBecause one of the basic axioms of equivalence relations (which equality should certainly be) is reflexivity; anything should be equal to itself, and other code will break if it isn't (e.g. in many languages you can corrupt a binary tree structure by inserting multiple NaNs into it, because they'll both compare less than each other). Maybe there are legitimate use cases for that kind of comparison, but you shouldn't use the conventional == operator for it. I think OCaml avoids the problem by having separate operators for floats, and Rust sort-of does by having a distinction between PartialEq and Eq.
- thwarted 5y ago> Because one of the basic axioms of equivalence relations (which equality should certainly be) is reflexivity; anything should be equal to itself, and other code will break if it isn't (e.g. in many languages you can corrupt a binary tree structure by inserting multiple NaNs into it, because they'll both compare less than each other). NaN is not something that can be pointed to. NaN doesn't exist like numbers exist in relation to each other, it's a concept (or at least more conceptual than numbers themselves are conceptual). NaN doesn't exist on a number line, so it makes no sense to order, compare for greater or less than, a NAN with numbers or anything else. It literally means "this doesn't exist". It doesn't have a "self" for reflexivity to apply to. A binary tree's nodes need to be comparable and orderable, and NaN is not comparable to anything. There is no place to put a NaN in a binary tree, nor is there really a use case to "find a NaN quickly" that a binary tree would be useful for (what would the utility be of a binary tree where the keys are all NaN?). NaN is a sentinel, and it exists outside the set of floats, despite being a float itself for type purposes, which is why it needs to be tested for using specific operators (isNaN) and not using equality operators. Part of the utility of NaN is that it can not be tested for using equality. Of course, computers are limited in what can be represented using bits, so NaN does have a specific (set of) binary representation(s), and you could work with those, but that avoids the useful abstraction NaN is mean to represent.