Is nan in (nan,) correct?

[Rustom Mody]

On Friday, March 6, 2015 at 3:57:12 AM UTC+5:30, rand... at fastmail.us wrote:
> It's been brought up on Stack Overflow that the "in" operator (on
> tuples, and by my testing on dict and list, as well as dict lookup) uses
> object identity as a shortcut, and returns true immediately if the
> object being tested *is* an element of the container. However, the
> contains operation does not specify whether object identity or equality
> is to be used. In effect, the built-in container types use a hybrid
> test: "a is b or a == b".
> 
> My question is, is this a *correct* implementation of the operator, or
> are objects "supposed to" use a basis of equality for these tests?

nan is an illegal or bogus value.
As usual legalizing the illegal is always fraught with increasing conundrums.

The most (to me) classic instance of this is denotational semantics.
In DS one tries to give semantics to programs by mapping programs to math-functions across some domains

However some programs crash. What should be the semantics of such a program.
We say its a partial function – undefined at the crash-points.
But partial functions are not nearly as tractable (to mathematicians!) as total
functions. 
So we invent a bogus value  ⊥ (called bottom) and totalize all functions by
mapping to this.

Very nice…

So nice in fact that we wish to add ⊥ to our programming language

And now all hell breaks loose because the question x == ⊥ is the halting problem.

And people love this problem so much they keep replicating it:

- C and null (or Pascal/Lisp and Nil)
[Hoare's billion dollar mistake https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions ]
- nul in SQL – Should two nuls compare as same or different?
  There are good (and different!) reasons for both answers
- Python and None
- Floats and nans

My own thoughts on this (not very well thought out, I admit)
The letter of the IEEE standard talks of nans and their details
The spirit of the standard is that nans capture exception-al computations
ie nan represents an exception

In a language like python with decent exceptions we do not need nans.

Of course there are all sorts of corner cases eg data source is something outside python etc