> (...)there aren't two things there at all, just one thing expressed two different ways (...) I have to respectully disagree with you :-) Consider for a mome

> (...)there aren't two things there at all, just one thing expressed two different ways (...) I have to respectully disagree with you :-) Consider for a moment ``3 + 0''. That expression (those three tokens) denote something we can talk and reason about. Now the important point: not because of some inherent property of the notation itself, but because we, the people, agreed what we mean by that expression. Contrast that with expression ``3 / 0'' -- which does not denote anything. Maybe, just maybe, there is something usefull that stems from division by zero, but! so far, we have not agreed upon what would be denoted by division by zero. We haven't agreed upon anything this expression would mean. It denotes no single thing, and neither a (nonempty) set of things. Of course, we have to somehow describe the fact of ``having nothing to say'' -- we use `NaN' -- but that's not a number symbol, that's a meta-symbol. Means, ``nothing to see there, my dear CPU, please move along''. Note also, how in SQL, the following does not hold true: NULL = NULL. In SQL, `NULL' doesn't stand for something, but for no thing at all. And whaddya know, division by zero yields NULL in SQL. * * * As for the equality itself (as opposed to assignment), so far we, the programmers, have only one common use for it -- checking whether data from some source ``equals'' data from another source. There are three common ways of doing that: 0) pointer equality. Fastest, simpliest, but won't suffice in some programming languages. Thing is, one kind of languages keep just single copy of all the same values (say, every variable that holds string "foobar" points to the same memory cell), but others do not, and here you need one of the two following ways. 1) value equality (== in JS): whether the two expressions ``evaluate'' to the same value. This has two downsides: is generally slower (the overhead of runtime evaluation), and often is governed by twisted rules reagarding type coercion. For example, in PHP, the following holds: 0 == "1". Fun fact to know and tell: those twisted rules stem from the language creators' desire to make programming easier. 2) type-and-value equality (=== in JS): this straightens some ofthe twisted rules of 1), due to comparing data types first (instead of prerforming type coercion), but otherwise does the same thing: compares value. May often be faster and also simplier to grasp, but also may blow up when you mix up data with different types. Which nb. is easy to overlook when data comes from data sources having different semantics or idioms. To put 1) and 2) in another way, those operations compare two values by their properties. Yet the NaN doesn't have properties to speak of, because it is not a value in the first palce. The operation of comparing is thus not well defined for NaN. Oops? :-)