float("nan") in set or as key

[Carl Banks]

On Sunday, May 29, 2011 8:59:49 PM UTC-7, Steven D'Aprano wrote:
> 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

Fine, it wasn't "unheard of".  I'm pretty sure the existence of a few high end compiler/hardware combinations that supported traps doesn't invalidate my basic point.  NaN was needed because few systems had a separate path to deal with exceptional situations like producing or operating on something that isn't a number.  When they did exist few programmers used them.  If floating-point were standardized today it might not even have NaN (and definitely wouldn't support the ridiculous NaN != NaN), because all modern systems can be expected to support exceptions, and modern programmers can be expected to use them.


> 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.

If your aim is to support every last clause of IEEE for better or worse, then yes that's what Python should do.  If your aim is to make Python the best language it can be, then Python should reject IEEE's obsolete notions, and throw exceptions when operating on NaN.


Carl Banks