That's the definition of NaN in virtually any programming language with floating point numbers. And the comparison table makes sense with the rule "when types are incompatible, both are casted to strings". Just use === instead of ==, which is only really useful for comparing against null/undefined.
> let x = 0/0
> x
NaN
> x == x
False
> :type x
x :: Double
The author programs in C++ and D. I wonder if he knows the value of (NaN == NaN) in those languages?
But, if you have code which compares one-element arrays with strings, you have bigger problems than javascript. I can't recall seeing any serious comparison Batman-style bug. Hypothetically, that kind of stuff wouldn't even be a logic bug, but a design issue that was allowed by the dynamic type system. Solution: don't bitch about Javascript, use something else.
A bird is not a rock. A computer is also not a rock. Clearly not equal to each other.
This violates: http://en.wikipedia.org/wiki/Law_of_identity
If (x == x) tests false, then it asserts that x is not itself, which is logically preposterous.
ANSI Common Lisp has a bit of this problem in it too, but it's not required; it is there for some weird historic implementations. That is to say, if x holds a number like 1, then (eq x x) is not required. (But in sane implementations it does yield t; and it yields t even if x is a bignum, because (eq x x) is given the same object as two arguments. Two separately computed bignums of equal value will likely, of course, not be eq.
How this can be explained is that eq tests "implementation identity", and somehow different instances of a number are treated as different implementations. Argument passing is by value, and the two reductions of the expression x in (eq x x) to a value somehow produce a different implementation of the value.
This rationale is unrelated to IEEE NaN-s, though.
Divisions by 0 can be thought of as infinity (for the sake of this explanation, but mathematicians will cringe), but it is not any particular infinity. In the sense that x / 0 does not necessarily have to equal y / 0. For that definition, the result of a division by 0, NaN, must not equal itself.
You can use `isNaN`, tho.
To drive the point home, this is somewhat like making 0xF different from 15.
Not wrong, but zero having a sign is useful for several complex plane algorithms--it's not just an accident.
As a general rule, anything that is in IEEE 754 (or 854) has a damn good reason for being there, and you had best take some time to understand it or risk looking stupid. A lot of hardware people screamed about a lot of the obnoxious software crap in IEEE 754, so, if something survived and made it into the standard, it had an initial reason for being there even if that reason has gone away with time/the advance of knowledge/Moore's Law.
The original designer's commentary about it is: William Kahan, "Branch Cuts for Complex Elementary Functions, or Much Ado About Nothing's Sign Bit", in The State of the Art in Numerical Analysis (eds. Iserles and Powell), Clarendon Press, Oxford, 1987.
First of all it is debatable over whether or not the spec allows (eq x x) to be false. eq is required to return true if the arguments are the same identical object. It would be a twisted interpretation of that to allow (eq x x) to ever return false.
Now (eq 1 1) is specifically not required to return true, as, for example an implementation that boxes all numbers could create two separate objects for that expression, and the arguments are now in fact not the same identical object.
This is something that exposes implementation details to the user, so using eq is discouraged (and in fact it can only portably be used to compare symbols). There are times when the best way to accomplish what you are doing is to (ab)use implementation specific behavior, and this is particularly true of Lisp which was a dynamically typed garbage collected language in the 70s (yes, predating the VT100 terminal referenced in this article).
"An implementation is permitted to make ``copies'' of characters and numbers at any time. The effect is that Common Lisp makes no guarantee that eq is true even when both its arguments are ``the same thing'' if that thing is a character or number. "
I stand by the rest of what I said. It's no more strange for (eq 1 1) to be false than (eql '(1) '(1))
(let ((x '(1)))
(eql x x))
It is strange for (eq x x) to be false, when x holds 1, or anything else; yet that appears to be allowed when it holds a number or character.
(eq 1 1) being nil caters to implementations that have heap allocated numbers. That is fine, but under (eq x x), both arguments should be the same heap-allocated 1.
(eq x x) being nil is nothing but pandering to some weird, historic implementations, whose quirk should never have been made ANSI conforming. I don't think it's relevant today.
Dismayingly, JavaScript's isNaN() function diverges from this special meaning, and does something close to what you said -- it tests to see if something is at least almost a number. So isNaN(13/0) and isNaN('foo') both evaluate to 'true', whereas isNaN('1') and isNaN(42) both evaluate to 'false'.
The idea was more like "isNaN(myForm.myField)"?
For all I know, the above might actually still work. But either way, that explains Javascript type conversion logic.
char *p = "abc";
p == p
I agree with making accesses of NaN-valued variables undefined behavior, so that not comparing equal is then a possible consequence of undefined behavior.
I don't agree with defining the unequal comparison as the required behavior. To define the behavior is tantamount to the recognition that a NaN is something: an object. A variable can have a defined value which is that something, and that value must obey the Law of Identity.
Why would it be? The rationale makes perfect sense. It would be unexpected to believe that 17/0 == 0^0. Both are NaN, and equally nonsense, but 2 very different statements.
Secondly, IIRC, NaN is supposed to break assert(x==x), because if you use NaN in your program, then your program is undefined.
The problem is that a NaN is not equal to itself:
double nan = /* NaN-producing expression */
if (nan == nan) {
/* dead code */
}Not saying it's the perfect way to handle things, but it's pretty reasonable in world where people write code that generates NaN almost every time they use division. I worry more about writing code that generates NaNs than NaNs themselves anyway.