96

The relevant IEEE standard defines a numeric constant NaN (not a number) and prescribes that NaN should compare as not equal to itself. Why is that?

All the languages I'm familiar with implement this rule. But it often causes significant problems, for example unexpected behavior when NaN is stored in a container, when NaN is in the data that is being sorted, etc. Not to mention, the vast majority of programmers expect any object to be equal to itself (before they learn about NaN), so surprising them adds to the bugs and confusion.

IEEE standards are well thought out, so I am sure there is a good reason why NaN comparing as equal to itself would be bad. I just can't figure out what it is.

The IEEE standards were designed by engineers, not programmers, computer vendors, or authors of math libraries, for whom the NaN rule is a disaster - Jim Balter 2014-04-08 07:20

28

My original answer (from 4 years ago) criticizes the decision from the modern-day perspective without understanding the context in which the decision was made. As such, it doesn't answer the question.

The correct answer is given here:

`NaN`

!=`NaN`

originated out of two pragmatic considerations:[...] There was no

`isnan( )`

predicate at the time that NaN was formalized in the 8087 arithmetic; it was necessary to provide programmers with a convenient and efficient means of detecting NaN values that didn’t depend on programming languages providing something like`isnan( )`

which could take many years

There was one disadvantage to that approach: it made NaN less useful in many situations unrelated to numerical computation. For example, much later when people wanted to use `NaN`

to represent missing values and put them in hash-based containers, they couldn't do it.

If the committee foresaw future use cases, and considered them important enough, they could have gone for the more verbose `!(x<x & x>x)`

instead of `x!=x`

as a test for `NaN`

. However, their focus was more pragmatic and narrow: providing the best solution for a numeric computation, and as such they saw no issue with their approach.

===

Original answer:

I am sorry, much as I appreciate the thought that went into the top-voted answer, I disagree with it. NaN does not mean "undefined" - see http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF, page 7 (search for the word "undefined"). As that document confirms, NaN is a well-defined concept.

Furthermore, IEEE approach was to follow the regular mathematics rules as much as possible, and when they couldn't, follow the rule of "least surprise" - see https://stackoverflow.com/a/1573715/336527. Any mathematical object is equal to itself, so the rules of mathematics would imply that NaN == NaN should be True. I cannot see any valid and powerful reason to deviate from such a major mathematical principle (not to mention the less important rules of trichotomy of comparison, etc.).

As a result, my conclusion is as follows.

IEEE committee members did not think this through very clearly, and made a mistake. Since very few people understood the IEEE committee approach, or cared about what exactly the standard says about NaN (to wit: most compilers' treatment of NaN violates the IEEE standard anyway), nobody raised an alarm. Hence, this mistake is now embedded in the standard. It is unlikely to be fixed, since such a fix would break a lot of existing code.

Edit: Here is one post from a very informative discussion. Note: to get an unbiased view you have to read the entire thread, as Guido takes a different view to that of some other core developers. However, Guido is not personally interested in this topic, and largely follows Tim Peters recommendation. If anyone has Tim Peters' arguments in favor of `NaN != NaN`

, please add them in comments; they have a good chance to change my opinion.

IMHO, having

`NaN`

violate trichotomy makes sense, but like you I see no reasonable semantic justification for not having `==`

define an equivalence relation when its operands are both of the same type (going a little further, I think languages should explicitly disallow comparisons between things of different types--even when implicit conversions exist--if such comparisons cannot implement an equivalence relation). The concept of an equivalence relations is so fundamental in both programming and mathematics, it seems crazy to violate it - supercat 2013-09-18 19:40
You might read on; Kahan says elsewhere in that document "NaNs must conform to mathematically consistent rules that were deduced, not invented arbitrarily[.]" I will agree that he doesn't mention *how*

`NaN != NaN`

is deduced beyond saying it's needed to distinguish `NaN`

from non-`NaN`

s absent library support like `isnan()`

- tmyklebu 2014-02-13 19:59
Note that even if we consider NaN to represent an unknown value (and hence each NaN *may* be unequal to another), we cannot conclude that two NaN values necessarily *are* unequal to one another. In short: it might make sense for NaN == NaN to itself return NaN (or some other representation for uncomputable in your language - undefined, a raised exception, etc.), but it's definitely weird to simply return false - Eamon Nerbonne 2014-03-28 07:45

@EamonNerbonne: Having

`NaN==NaN`

return something other than true or false would have been problematic, but given that `(a<b)`

does not necessarily equal `!(a>=b)`

, I see no reason that `(a==b)`

must necessarily equal `!(a!=b)`

. Having `NaN==NaN`

and `Nan!=NaN`

both return false would allow code which needs either definition of equality to use the one it needs - supercat 2014-04-29 23:28
This answer is WRONG WRONG WRONG! See my answer below - russbishop 2014-05-14 22:47

You generally don't run across NaNs. The only way you can compute one is to ask for something that isn't mathematically defined. Once you've decided to have an error value, the question is "what semantics are least likely o cause trouble?" I believe that always returning false **is** the safest thing to do. So you get mis-sorted containers, how harmful is that? Especially compared to alternatives - Max Lybbert 2014-05-14 23:08

I am not aware of any axiom or postulate that states a mathematical object (how do you even define a mathematical object????) has to equal itself - Transcendence 2014-05-14 23:23

Even if your based on the identity function f on a set S where f(x) = x, I would argue that NaN is not part of the set of numbers, after all, it's literally not a number. So I don't see any argument from the identity function that NaN should equal itself - Transcendence 2014-05-14 23:25

With regards to your comment on trichotomy, trichotomy is an order relation on a set of numbers. Again I would argue that NaN is not in the set of numbers. I don't see anything in the IEEE specification that says it is, although I might have missed it - Transcendence 2014-05-14 23:34

@Transcendence Look up the "Law of Identity". The concept of equality (and it's brothers consistency and completeness) are way too complex to be handled in a comment; but I will say that if you assume x=x can be false; you have opened up a giant can of worms you have to deal with before we can even consider the identify function has since the "=" in f(x)=x is not well defined - Chuu 2014-06-19 13:48

@chuu look up Dialetheis - Transcendence 2014-06-19 17:20

This is wrong. Please see the top voted question below by russbisho - Hejazzman 2017-06-27 14:08

@Hejazzman what exactly is wrong? My original answer? My updated answer? The comment just above yours? Or any other particular statement - max 2017-06-29 03:46

I would not even consider the possibility that, "IEEE committee members did not think this through very clearly, and made a mistake. " without either Investigating the committee members enough to assure myself that they are not actually experts or an expert (ideally person on the IEEE committee or a compiler writer) making the same complaint. IEEE is both important and a burden to implement, so discussions of it are not uncommon. You at least found a discussion involving such an expert. However, I find your reasoning was wrong, rather than merely your conclusion - Brian 2018-05-02 13:44

135

**The accepted answer is 100% without question WRONG**. Not halfway wrong or even slightly wrong. I fear this issue is going to confuse and mislead programmers for a long time to come when this question pops up in searches.

NaN is designed to propagate through all calculations, infecting them like a virus, so if somewhere in your deep, complex calculations you hit upon a NaN, you don't bubble out a seemingly sensible answer. Otherwise by identity NaN/NaN should equal 1, along with all the other consequences like (NaN/NaN)==1, (NaN*1)==NaN, etc. If you imagine that your calculations went wrong somewhere (rounding produced a zero denominator, yielding NaN), etc then you could get wildly incorrect (or worse: subtly incorrect) results from your calculations with no obvious indicator as to why.

There are also really good reasons for NaNs in calculations when probing the value of a mathematical function; one of the examples given in the linked document is finding the zeros() of a function f(). It is entirely possible that in the process of probing the function with guess values that you will probe one where the function f() yields no sensible result. This allows zeros() to see the NaN and continue its work.

The alternative to NaN is to trigger an exception as soon as an illegal operation is encountered (also called a signal or a trap). Besides the massive performance penalties you might encounter, at the time there was no guarantee that the CPUs would support it in hardware or the OS/language would support it in software; everyone was their own unique snowflake in handling floating-point. **IEEE decided to explicitly handle it in software as the NaN values so it would be portable across any OS or programming language. Correct floating point algorithms are generally correct across all floating point implementations**, whether that be node.js or COBOL (hah).

In theory, you don't have to set specific #pragma directives, set crazy compiler flags, catch the correct exceptions, or install special signal handlers to make what appears to be the identical algorithm actually work correctly. Unfortunately some language designers and compiler writers have been really busy undoing this feature to the best of their abilities.

Please read some of the information about the history of IEEE 754 floating point. Also this answer on a similar question where a member of the committee responded: What is the rationale for all comparisons returning false for IEEE754 NaN values?

"An Interview with the Old Man of Floating-Point"

"History of IEEE Floating-Point Format"

What every computer scientist should know about floating point arithmetic

I also like NaN to propagate "like a virus". Unfortunately, it doesn't. The moment you compare, for example,

`NaN + 1 != 0`

, or `NaN * 1 > 0`

, it returns `True`

or `False`

as if everything was fine. Therefore, you can't rely on `NaN`

protecting you from problems if you plan to use comparison operators. Given that comparisons won't help you "propagate" NaNs, why not at least make them sensical? As things stand, they mess up the use cases of NaN in dictionaries, they make sort unstable, etc.
Also, a minor mistake in your answer. `NaN/NaN == 1`

would not evaluate `True`

if I had my way - max 2014-05-17 11:03

Also, you claim that my answer is 100% positively absolutely WRONG. However, the person on the IEEE committee whom you quoted actually stated in the very post you quoted:

`Many commenters have argued that it would be more useful to preserve reflexivity of equality and trichotomy on the grounds that adopting NaN != NaN doesn’t seem to preserve any familiar axiom. I confess to having some sympathy for this viewpoint, so I thought I would revisit this answer and provide a bit more context.`

So maybe, dear Sir, you might consider being a bit less forceful in your statements - max 2014-05-17 11:16
I understand, but I wanted it to be 100% clear to new developers or those not interested in the details of floating point that your statement that the committee made a "mistake" was incorrect - the design was deliberate - russbishop 2014-05-24 03:49

I never said the design wasn't deliberate. A deliberate design guided by poor logic or poor understanding of the problem is still a mistake. But this discussion is pointless. You clearly possess the knowledge of the ultimate truth, and your job is to preach it to the uneducated masses like myself. Enjoy the priesthood - max 2014-05-28 11:07

Ignoring your snark, I explained the decision to you: at the time there was little chance of uniform handling of exceptions/signals across languages, compilers, hardware, and operating systems. The decision was made to handle NaN as a bit pattern so it would be completely portable, since it is useful in actual calculations. I think that's the correct decision, you disagree, but the decision was not guided by poor logic or poor understanding - russbishop 2014-05-29 02:50

Spreading NaN through calculations is completely unrelated to equality comparisons with NaN. Portability and implementing NaN as a bit pattern is also immaterial for the question whether NaN should compare equal to itself or not. In fact, I can't find any rationale for NaN != NaN in this answer, except for the first linked answer at the bottom, which explains that the reason was the unavailability of

`isnan()`

at the time, which is valid reason why the decision was taken. However, I can't see any reason that is still valid today, except that it would be a very bad idea to change the semantics - Sven Marnach 2015-10-08 11:22
@SvenMarnach That's not correct. NaN means the answer is unknown. Trying to compare NaN is semantically meaningless. Look at the second answer below... should log(-1) == acos(2)? Because if NaN == NaN then they do which is obvious nonsense. If most languages, platforms, and CPUs had supported trapping/throwing exceptions at the time then the standard might have chosen that route instead of NaN. They didn't. Most developers misuse floating point anyway, you shouldn't be comparing for direct equality most of the time anyway - russbishop 2016-02-10 08:32

@xenadu I can see that log(-1) == acos(2) provides some argument in favour of the current behaviour. However, you noticed yourself that you shouldn't be comparing floating point numbers for equality anyway, so that's kind of a weak argument (and there are many reasons to decide the other way). However, that wasn't the point of my previous comment. My point was that the answer above, while correct, does not give any reasons why NaN shouldn't compare equal to itself. Everything you talk about is completely unrelated to that question - Sven Marnach 2016-02-10 16:12

@SvenMarnach It does directly relate because you don't know a priori that the values in some

`x`

and `y`

are NaN so comparing them as equal would be an invalid answer - russbishop 2016-02-10 19:40
@xenadu but comparing them as not equal would also be an invalid answer. Should log(-1) == log(-1)? IMO == and != are both incorrect when it comes to comparing two NaN's, but for the sake of practicality == breaks a lot less laws, and a lot less containers - semicolon 2016-03-30 01:24

Some of the consequences you describe are not true, and the rest are off topic. For instance, "Otherwise by identity NaN/NaN should equal 1." The standard itself violates this reasoning. Infinity == Infinity, and yet Infinity / Infinity == NaN, not 1. Clearly, therefore it is possible for both NaN == NaN and NaN / NaN == NaN. Secondly, the statement (NaN*1)==NaN MUST BE TRUE for NaN to "propagate through all calculations" as you yourself said. These supporting statements are wrong, and NONE of your cited sources claim them. Rather, your first source says it was to satisfy isnan(x) = (x != x - Mike Fairhurst 2016-05-05 00:41

There's a semantic difference between Infinity and NaN though. Infinity has a mathematical meaning. Not a number quite literally means the answer is nonsense. As a programmer I understand the knee-jerk reaction to having two "apparently" equal values compare not equal. Floating point doesn't fit neatly into boolean logic (in more ways than one) - russbishop 2016-05-05 05:33

The statement "Otherwise by identity NaN/NaN should equal 1" is a mathematical statement/rule. Are you are trying to say that your mathematical rule does not apply to Infinity because Infinity is a mathematical concept? Obviously that's not true. The real rule is here: http://math.stackexchange.com/questions/1773367/what-is-the-rule-for-something-divided-by-itself-equaling-1/1773378#1773378 It does not apply to infinity, because no value x times infinity equals 1. Similarly, no value x times NaN equals 1. Rather than argue with your commenters, please provide sources, as you still have none - Mike Fairhurst 2016-05-05 22:46

91

Well, `log(-1)`

gives `NaN`

, and `acos(2)`

also gives `NaN`

. Does that mean that `log(-1) == acos(2)`

? Clearly not. Hence it makes perfect sense that `NaN`

is not equal to itself.

Revisiting this almost two years later, here's a "NaN-safe" comparison function:

```
function compare(a,b) {
return a == b || (isNaN(a) && isNaN(b));
}
```

What is the situation where assuming them to be equal (in a real application, not in mathematics) would be a problem - max 2012-04-05 18:51

In other words, *undefined*. By definition, you can’t reasonably assert that some undefined value is equal to another one - Jon Purdy 2012-04-05 18:52

`NaN`

just means Well, if you were looking for an intersection between the

`log`

function and the `acos`

function, then all negative values past `-1`

would be considered an intersection. Interestingly, `Infinity == Infinity`

is true, despite the fact that the same can't be said in actual mathematics - Niet the Dark Absol 2012-04-05 19:05
Given that Inf == Inf, and given that one might just as easily argue that an object should be equal to itself, I suspect there was some other, very specific and very strong, rationale behind the IEEE choice.. - max 2012-04-05 20:04

The reason inf==inf is that floating point arithmetic is not exact; it's subject to rounding (by default, round-to-nearest). Similarly, 1.0==1.0 might evaluate true in floating point even when the expressions that generated the 1.0's were not exactly equal, because the equality holds after rounding - R.. 2012-04-06 02:27

`1 + 3 = 4`

and `2 + 2 = 4`

. Does that mean that `1 + 3 = 2 + 2`

? Clearly yes. Hence your answer does not make perfect sense - borisdiakur 2012-07-20 21:33
I think it would make more sense if you look at an invertible function (such as

`log`

, `sqrt`

, or `parseInt`

) that is called with two different arguments - you expect `f(a)=f(b) <=> a=b`

. Now `-3!=2 <=> acos(-3)!=acos(2) => NaN!=NaN`

Bergi 2013-04-02 13:08
But

`log(-1) != log(-1)`

does not make sense. So neither `NaN`

equals `NaN`

nor `NaN`

does not equal `NaN`

makes sense in all cases. Arguably, it'd make more sense if `NaN == NaN`

evalutated to something representing unknown, but then `==`

wouldn't return a boolean - Tim Goodman 2013-06-28 16:39
@Bergi: I certainly wouldn't expect that *can* expect is that

`f(a)=f(b) <=> a=b`

this would only hold if f was an injective function. But f could be constant. What one `a=b => f(a)=f(b)`

, but then your argument does not apply - Max 2013-09-09 01:12
Even if one thinks

`NaN==NaN`

should return false, why should that imply that `NaN!=NaN`

should return true? Given that `NaN < NaN`

and `NaN >= NaN`

both return false, even though they're "opposite" conditions, why could not `NaN == NaN`

and `NaN != NaN`

both return true - supercat 2014-02-11 00:40
@supercat Because maybe they are equal. It all depends on how the

`NaN`

was obtained - Niet the Dark Absol 2014-02-11 00:42
@NiettheDarkAbsol: I meant "both return false". If the fact that the things might not be equal is sufficient reason for

`==`

to return false, would not the the fact that they might be equal be adequate reason for `!=`

to also return false? The idea of equivalence relations is a very useful one, but I know of no nice way using only IEEE operations to test whether x and y are equivalent except (!(x < y) && !(x > y)); being able to test `!(x == y)`

would seem much cleaner - supercat 2014-02-11 02:21
1/x == 2/x for large enough x, but 1 != 2. Floats aren't reals, so something have to give somewhere (actually an infinity of somewheres). x != x where x is a NaN is a truly sucky place to give, when isnan() can be implemented in other ways -- and it makes it extremely difficult to design template libraries over numerics that function according to spec - Jim Balter 2014-04-08 07:32

"why could not NaN == NaN and NaN != NaN both return true?" -- that would be even worse than x = NaN; x != x because it would ban any language in which (a != b) is defined to be equivalent to !(a == b) - Jim Balter 2014-04-08 07:38

@JimBalter: I meant "both return false". As it is, the

`!=`

operator is redundant with `==`

, while the other "opposite" forms allow a single test to specify the desired behavior when comparing `NaN`

with itself [e.g. `!(a > b)`

is equivalent to `a <= b`

except that the former returns true for `NaN`

and the latter false. If `Nan != NaN`

were false, then code which wanted to test equivalence could test `!(a != b)`

rather than having to use `!(a < b) && !(b < a)`

- supercat 2014-04-29 23:20
@supercat Same answer - Jim Balter 2014-04-29 23:32

@JimBalter: What languages would compel

`a==b`

to be equivalent to `!(a!=b)`

but not also compel `a>b`

to be equivalent to `!(a<=b)`

? Also, can you suggest any usage cases where `NaN!=NaN`

is helpful, which are anywhere near as common as checking whether a value has been stored in a set? If a language can't support two different meanings for equality, specifying that code which wants to test if two things are equal non-NaNs should use `(x<=y)||(x>=y)`

would seem less annoying that saying that what would otherwise be type-agnostic equivalence-testing code must special-case floats - supercat 2014-04-29 23:51
@supercat You are neither going to change the IEEE spec nor change languages in which (a != b) is defined as !(a == b), so this discussion is moot and I'm no longer interested in it - Jim Balter 2014-05-01 05:30

Your NaN-safe comparison function returns true if you supply two different numbers which aren't equal to each other. Something like return a == b || (isNaN(a) && isNaN(b)) should work - mmitchell 2014-05-14 22:45

@mmitchell Thank you, kind of embarrassing now I think about it X - Niet the Dark Absol 2014-05-15 08:42

The *symbolic equality* (or equivalence) and the other is *absolute exactness* (or equality or identity). In my opinion, *equivalent* to *equal* to *same in meaning* but not *exact in value* - nawfal 2015-11-24 11:39

`log(-1)`

and `acos(2)`

examples make it clear why `NaN`

shouldn't be equal to itself. I think it's better to have two separate idioms when testing for equality of two `NaN`

s. One, is `NaN`

is `NaN`

but not `NaN`

. `log(-1)`

and `acos(2)`

can be considered I would love to see an idiom like this in programming languages:

`NaN == NaN; true`

, `NaN != NaN; false`

, `NaN === NaN; false`

, `NaN !== NaN; false`

. As supercat says I don't get why PHP, JS etc have designed it like `NaN == NaN; false`

and `NaN != NaN; true`

. The same question raise for `Null`

s as well. Some platforms consider them equal, some not. If only we could have one opinion on this - nawfal 2015-11-24 11:42
@nawfal While that would be cool, ideally you should be checking for

`NaN`

s and `Null`

s before attempting to do stuff with them : - Niet the Dark Absol 2015-11-24 12:44
@NiettheDarkAbsol or as Bitsios says any operation on NaN should return NaN, clearly which indicates the result is not defined as well : - nawfal 2015-11-24 13:08

@borisdiakur **Firstly**, there is a small difference between 2 things being equal & 2 things being considered equal. In programming when you write **considering** **is** mathematically equal to *is also* equal. **equal** to **result** in

`var x = some_func(y)`

we are `x`

to be equal to RHS. On the other hand `1 + 3`

`4`

. It's a side-effect that the addition function or operator return a value that `1 + 3`

is `4`

. `log(-1)`

`NaN`

. To make it amply clear, even though `log(-1)`

result in `NaN`

, it should be noted `log(-1) == NaN`

fails in many languages. Whether this should fail is the question - nawfal 2015-11-24 13:23
@borisdiakur **Secondly**, to talk of your specific eg, . That's why **is the value **? The and the debate is on what should be the behavior. Just because some operator operates on two operands **of one kind** in one way doesn't mean it should operate on operands **of any kind** the same way. To assert

`1 + 3`

and `2 + 2`

result in `4`

, and `4 == 4`

`1 + 3 = 2 + 2`

. `log(-1)`

and `acos(2)`

result in `NaN`

but `NaN`

equal to `NaN`

`==`

in 1st case operates on two numbers. Their behavior is well defined. `NaN`

is not a number`NaN == NaN`

because `4 == 4`

leads to a circular argument - nawfal 2015-11-24 13:27
Of course it is confusing since most things we know have followed reflexivity but it is important to know the distinction - nawfal 2015-11-24 13:27

Clearly, the solution is to have a tri-state boolean system, like some flavors of SQL have, where the result of any comparison on

`NaN`

is `IdK`

(I don't Know) - JLRishe 2017-10-27 05:53
@JLRishe True/False/IdK would cover more cases, definitely - Niet the Dark Absol 2017-10-27 09:28

7

A nice property is: if `x == x`

returns false, then `x`

is `NaN.`

(one can use this property to check if `x`

is `NaN`

or not.)

One could have that property and still have (Nan != Nan) *also* return false. Had the IEEE done that, code which wanted to test an equivalence relation between

`a`

and `b`

could have used `!(a != b)`

- supercat 2014-02-11 00:38
That's a great substitute for np.isnan() and pd.isnull() ! - Statham 2016-12-19 02:57

6

Try this:

```
var a = 'asdf';
var b = null;
var intA = parseInt(a);
var intB = parseInt(b);
console.log(intA); //logs NaN
console.log(intB); //logs NaN
console.log(intA==intB);// logs false
```

If intA == intB were true, that might lead you to conclude that a==b, which it clearly isn't.

Another way to look at it is that NaN just gives you information about what something ISN'T, not what it is. For example, if I say 'an apple is not a gorilla' and 'an orange is not a gorilla', would you conclude that 'an apple'=='an orange'?

"that might lead you to conclude that a==b" -- But that would simply be an invalid conclusion -- strtol("010") == strtol("8"), for instance - Jim Balter 2014-04-08 07:42

I don't follow your logic. Given *indistinguishable* results? Why should not sqrt(-1) and (0.0/0.0) be considered indistinguishable, absent a means of distinguishing them - supercat 2014-04-29 23:25

`a=16777216f`

, `b=0.25`

, and `c=0.125`

, should the fact that `a+b == a+c`

be taken to imply that `b==c`

? Or merely that the two calculations yield If you are implying that indistinguishable things should be considered equal, I don't agree with that. Equality implies that you DO have a means of distinguishing two subjects of comparison, not just an identical lack of knowledge about them. If you have no means of distinguishing them, then they may be equal or they may not be. I could see NaN==NaN returning 'undefined', but not true - Mike C 2014-04-30 12:15

@MikeC pretty much nailed the reason without too much gramma - Ody 2014-10-23 01:05

So many answers, and I could only understood what you explained, kudos! - Kushal 2015-02-25 09:26

Hmm this is interesting. It seems like a tradeoff: ruin the reflexivity of

`==`

in order to preserve transitivity - Alexander 2015-06-29 16:19
2

Actually, there is a concept in mathematics known as “unity” values. These values are extensions that are carefully constructed to reconcile outlying problems in a system. For example, you can think of ring at infinity in the complex plane as being a point or a set of points, and some formerly pretentious problems go away. There are other examples of this with respect to cardinalities of sets where you can demonstrate that you can pick the structure of the continuum of infinities so long as |P(A)| > |A| and nothing breaks.

DISCLAIMER: I am only working with my vague memory of my some interesting caveats during my math studies. I apologize if I did a woeful job of representing the concepts I alluded to above.

If you want to believe that NaN is a solitary value, then you are probably going to be unhappy with some of the results like the equality operator not working the way you expect/want. However, if you choose to believe that NaN is more of a continuum of “badness” represented by a solitary placeholder, then you are perfectly happy with the behavior of the equality operator. In other words, you lose sight of the fish you caught in the sea but you catch another that looks the same but is just as smelly.

Yes, in math you can add infinity and similar values. However, they will never break the equivalence relationship. Programmers' equality represents an equivalence relation in math, which is by definition reflexive. A bad programmer can define

`==`

that is not reflexive, symmetric and transitive; it's unfortunate that Python won't stop him. But when Python itself makes `==`

non-reflexive, and you can't even override it, this is a complete disaster from both practical viewpoint (container membership) and elegance/mental clarity viewpoin - max 2013-03-19 20:42