I ran into this while debugging some numerical stuff. Consider this: js> p0 = 0.0 0 js> n0 = -0.0 0 js> p0 0 js> n0 0 js> p0 == n0 true js> p0 === n0 true js> 1/p0 Infinity js> 1/n0 -Infinity p0 and n0 are sometimes equivalent and sometimes not. I would js should be consistent. It's not a major issue, though.
Confirming reported behavior in current JS shell on WinNT, Linux. Reassigning to Kenton. I've taken a look at the ECMA spec but am not able to come up with the right answer. cc'ing Waldemar for help -
Assignee: rogerl → khanson
Behaves correctly. According to the ECMA spec: ToString Applied to the Number Type, if the number is +0 or -0 return "0". Not my first choice of behavior. Furthermore ECMA states that the equals operator (==) and the strict equals operator (===) is always true for -0 when compared to +0 or vice versa.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
Yes, I grumbled too when I first saw the spec. I'll save you the long history, but it does make sense in a kind of perverse way. I'm still fuming over NaN !== NaN, which means that === is not an equivalence operator at all.
Marking Verified; thanks to all. This is an interesting problem. Here is the specification on |===| that Kenton referred to above : 11.9.6 The Strict Equality Comparison Algorithm The comparison x === y, where x and y are values, produces true or false. Such a comparison is performed as follows: 1. If Type(x) is different from Type(y), return false. 2. If Type(x) is Undefined, return true. 3. If Type(x) is Null, return true. 4. If Type(x) is not Number, go to step 11. 5. If x is NaN, return false. 6. If y is NaN, return false. 7. If x is the same number value as y, return true. 8. If x is +0 and y is -0, return true. 9. If x is -0 and y is +0, return true. etc. Since +0 and -0 are treated as distinct values throughout the spec, steps 8, 9 are hard to accept...
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.