float("nan") in set or as key

[Steven D'Aprano]

On Sun, 29 May 2011 17:55:22 -0700, Carl Banks wrote:

> Floating point arithmetic evolved more or less on languages like Fortran
> where things like exceptions were unheard of, 

I'm afraid that you are completely mistaken.

Fortran IV had support for floating point traps, which are "things like 
exceptions". That's as far back as 1966. I'd be shocked if earlier 
Fortrans didn't also have support for traps.

http://www.bitsavers.org/pdf/ibm/7040/C28-6806-1_7040ftnMathSubrs.pdf


The IEEE standard specifies that you should be able to control whether a 
calculation traps or returns a NAN. That's how Decimal does it, that's 
how Apple's (sadly long abandoned) SANE did it, and floats should do the 
same thing.

Serious numeric languages like Fortran have supported traps long before 
exceptions were invented.



> and defining NaN != NaN
> was a bad trick they chose for testing against NaN for lack of a better
> way.

That's also completely wrong. The correct way to test for a NAN is with 
the IEEE-mandated function isnan(). The NAN != NAN trick is exactly that, 
a trick, used by programmers when their language or compiler doesn't 
support isnan().

Without support for isinf(), identifying an INF is just as hard as 
identifying an NAN, and yet their behaviour under equality is the 
complete opposite:

>>> inf = float('inf')
>>> inf == inf
True


> If exceptions had commonly existed in that environment there's no chance
> they would have chosen that behavior; 

They did exist, and they did choose that behaviour.


> comparison against NaN (or any
> operation with NaN) would have signaled a floating point exception. 
> That is the correct way to handle exceptional conditions.
> 
> The only reason to keep NaN's current behavior is to adhere to IEEE, 

And because the IEEE behaviour is far more useful than the misguided 
reliance on exceptions for things which are not exceptional.

Before spreading any more misinformation about IEEE 754 and NANs, please 
learn something about it:

http://grouper.ieee.org/groups/754/
http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps

I particularly draw your attention to the FAQ about NANs:

http://grouper.ieee.org/groups/754/faq.html#exceptions


[quote]
The 754 model encourages robust programs. It is intended not only for 
numerical analysts but also for spreadsheet users, database systems, or 
even coffee pots. The propagation rules for NaNs and infinities allow 
inconsequential exceptions to vanish. Similarly, gradual underflow 
maintains error properties over a precision's range. 

When exceptional situations need attention, they can be examined 
immediately via traps or at a convenient time via status flags. Traps can 
be used to stop a program, but unrecoverable situations are extremely 
rare. Simply stopping a program is not an option for embedded systems or 
network agents. More often, traps log diagnostic information or 
substitute valid results. 

Flags offer both predictable control flow and speed. Their use requires 
the programmer be aware of exceptional conditions, but flag stickiness 
allows programmers to delay handling exceptional conditions until 
necessary.
[end quote]



-- 
Steven