NaN comparisons - Call For Anecdotes

[Rustom Mody]

On Tuesday, July 8, 2014 8:23:47 PM UTC+5:30, Anders J. Munch wrote:
> Most people don't need to deal with NaN's in Python at all,
> fortunately. They just don't appear in normal computation, because the
> interpreter raises an exception instead.

> So I make this claim: float.__eq__ implementing IEEE-754 NaN
> comparison rules creates real problems for developers. And it has
> never, ever, helped anyone do anything.

> "Never" is a strong claim, and easily disproven if false: Simply
> provide a counterexample.  So that is my challenge: If you have a

No I dont have a direct answer for your challenge but I have two close analogies.

Nan in floats is analogous (almost isomorphic) to two other areas
- null in RDBMS
- bottom – ⊥ – in denotational semantics 

The denotational semantics example would really clarify the issue.
I have discussed it here in the haskell context:
http://blog.languager.org/2012/08/functional-programming-philosophical.html

http://en.wikibooks.org/wiki/Haskell/Denotational_semantics#.E2.8A.A5_Bottom
is a more general survey

RDBMS nulls is probably a more familiar example.

Lets say you have a dbms of people and one nullable field is 'telephone'.

Now some people have no phones and the original intent of the nullable 
field was to take care of that.

But then in data entry some people who had too many phones and could not
decide which to fill kept the field null!!

Are these two cases equivalent?  Your request amounts to making them so.

Now read your own case:

> It happens in my work I come across them quite a lot. I'm writing
> software that talks to embedded applications that can contain NaN
> values for a variety of reasons - never-initialised storage,
> initialise-to-NaN, hardware failures etc.

How do you decide that all these are equivalent/ 'equal'?

Someone or other somewhere or other will be unhappy!!

My analysis of the problem:

The *letter* of the IEEE standard describes nans (and other exotic beasties)
The *spirit* describes exceptional conditions that arise in floating computations
[I have not read the standard -- just guessing]

The standard was made when programming languages did not have well tried and
tested exception mechanisms.

So with python supporting nans we have two competing exception mechanisms:
- the IEEE one -- nans
- the native python one -- exceptions

Once this is clear it should be clear what the solution should be:
DRY, no redundancy etc.

Since exceptions are pythonic, nans should not be supported.

If we were starting from scratch this would be the way to go.
However given the currently extant support, this would be a downgrade for
people like you -- who would be unhappy!

So intermediate more kludgy solution:

The problem is not with

>>> nan==nan
False

But with

>>> type(nan)
<class 'float'>

So nan is a float but by definition is not a number!!

So float a superset of all numbers??!!

If instead like:
>>> type(None)
<class 'NoneType'>

we had
>>> type(None)
<class 'NanType'>

then normal users would never see it
and people like you could deal with it outside the float-umbrella.