4 ms·
Wait, am I reading this right? [1] == [1] is false, but [1] == 1 and 1 == [1]? [0] == [0] is false, but [0] == '0' and '0' == [0]? [] == [] is false but [] =
by TheLoneWolfling 13y ago
Wait, am I reading this right?
[1] == [1] is false, but [1] == 1 and 1 == [1]?
[0] == [0] is false, but [0] == '0' and '0' == [0]?
[] == [] is false but [] == 0 and 0 == []?
NaN === NaN is false?
[0] + [0] = '00', but [0] * [0] = 0?
Who designed this crazy language? It seems to take every quirk of every other language and combine them in the weirdest way possible.
[] == [] is false, so it must be comparing pointers, right? Common gotcha of Java, etc.
...Wait, NaN === NaN is false.
- swang 13y agoNaN == NaN should return false.
- jrajav 13y agoNaN !== NaN is intended, and is the same in any other language that has NaN. It is never supposed to be equal to anything else, not even itself. As for the rest of those quirks, they mainly have to do with type coercion, the rules for which are not as difficult to learn as the whole table in the submission. The fact that type coercion is performed for == is why nobody uses ==. You also should never try + or * on arrays (and why would you?). With some simple best practices, you never end up running into most of these quirks in practice.
- kevincennis 13y agoAnother fun thing about NaN is that typeof NaN === 'number'. Which, you know... seems counterintuitive based on the fact that NaN means "Not a number".
- Dylan16807 13y agoEh. 'number' means 'IEEE 754 floating point value' and NaN is certainly one of those. Abbreviations are tricky.
- kevincennis 13y agoYeah, I understand why. I was just pointing out that on the surface, it seems kind of weird.
- lifthrasiir 13y agoSome explanations: The rule of thumb is that, == does type coercion only when at least one of operands is primitive (non-Object), and does only the identity check otherwise. Therefore: [1] != [1] since both [1] are distinct arrays; [1] == 1 since 1 is primitive so [1] gets converted to primitive, in this case, '1', and '1' == 1. (The conversion to primitive is complicated, mainly because it has to select between ToNumber and ToString depending on the context. See Section 9.1 of ECMA-262 5th edition.) Likewise, [] == 0 since [] gets converted to '' and coerced to 0. NaN != NaN is a well-known facet of IEEE 754 floating point system, and you'll see similar phenomenon in SQL's NULL handling. [0] + [0] == '00' since both operands are coerced to string (no numeric operands there, so we assume both operands will eventually become string); [0] * [0] == 0 since both operands are coerced to number (no multiplication on string). ...Yeah, I agree on your thesis that ECMA-262 is seriously f*cked up.
- epidemian 13y agoAs others have pointed out, NaN == NaN being false is not surprising (at least according to IEEE floating point semantics ;). I kinda makes sense if you consider that both 0/0 and Infinity0 evaluate to NaN. `0/0 == Infinity0` being true would be an even weirder behaviour.
- TheZenPsycho 13y agoNaN is mostly equivalent to the _mathematical_ concept of undefined. It cannot be equal to anything, even itself, because there are multiple mathematical operations that can result in NaN that are not equivalent in value. Considering their result equivalent would be in error. in a NaN === NaN world, (1/0)*0 === 0/0 is true.
- kbenson 13y agoThere's a reason why Perl separates numeric and string operators, and it's not just to make it confusing for people.