float("nan") in set or as key

[Steven D'Aprano]

On Fri, 03 Jun 2011 13:27:00 -0700, Carl Banks wrote:

> On Wednesday, June 1, 2011 5:53:26 PM UTC-7, Steven D'Aprano wrote:
[...]
>> On the contrary, it blows it out of the water and stomps its corpse
>> into a stain on the ground.
> 
> Really?  I am claiming that, even if everyone and their mother thought
> exceptions were the best thing ever, NaN would have been added to IEEE
> anyway because most hardware didn't support exceptions.

You can claim that the Atlantic Ocean is made of strawberry yoghurt too, 
if you like, but that doesn't make it true.

The standard was written by people who made and used hardware that *did* 
support exceptions (hardware traps). They wrote code in languages that 
supported traps (mostly Fortran). The IEEE-754 standard mandates 
exceptions (not in the sense of Python exceptions, but still exceptions), 
and recommends various exception handling mechanisms, including try/catch.

NANs weren't invented because the standard writers didn't have a way of 
performing exceptions. You are simply *completely wrong* on that claim. 
There are plenty of documents about the IEEE-754 standard, including 
draft copies of it, and interviews with some of the participants. Go do 
some reading before spreading more misapprehensions.



> You are saying that the existence of one early system that supported
> exceptions not merely argument against that claim, but blows it out of
> the water?  Your logic sucks then.

Not one. ALL OF THEM. All of the manufacturers who were involved in the 
IEEE-754 standard had traps: Intel, Cray, DEC, CDC, Apple, and Intel. 
There may have been CPUs at the time that didn't have traps, but they 
weren't used for numeric work and they didn't matter. Traps were a 
standard mechanism used in numeric work.


> You want to go off arguing that there were good reasons aside from
> backwards compatibility they added NaN, be my guest.  Just don't go
> around saying, "Its in IEEE there 4 its a good idear LOL".  Lots of
> standards have all kinds of bad ideas in them for the sake of backwards
> compatibility, and when someone goes around claiming that something is a
> good idea simply because some standard includes it, it is the first sign
> that they're clueless about what standarization actually is.

No, I don't think that supporting NANs is useful merely because it is a 
standard. I've *repeatedly* said that NANs are useful as an alternative 
to exceptions, so don't misrepresent what I say.


[...]
> Here's the problem: Python is not for serious numerical programming.

I disagree. So do the numpy and scipy communities, and sage, and 
matplotlib. So do the Python developers: Python now has a fully IEEE-754 
compliant Decimal implementation. (What I want is floats to be equally 
compliant. I don't care if they default to raising exceptions.)

Despite it's weaknesses, Python is a good alternative to things like 
Mathematica and Matlab (which of course have weaknesses of their own), 
and it's not just me comparing them:

http://vnoel.wordpress.com/2008/05/03/bye-matlab-hello-python-thanks-sage/
http://www.larssono.com/musings/matmatpy/index.html
http://blog.revolutionanalytics.com/2009/07/mathematica-vs-matlab-vs-python.html


> Yeah, it's a really good language for calling other languages to do
> numerical programming, but it's not good for doing serious numerical
> programming itself.  Anyone with some theoretical problem where NaN is a
> good idea should already be using modules or separate programs written
> in C or Fortran.

And since Python is intended to be the glue between these modules, how 
are you supposed to get data containing NANs between these modules unless 
Python supports NANs?

I shouldn't have to fear running a snippet of Python code in case it 
chokes on a NAN. That cripples Python's usefulness as a glue language for 
numeric work.


> Casual and lightweight numerical work (which Python is good at) is not a
> wholly separate problem domain where the typical rules ("Errors should
> never pass silently") should be swept aside.

NANs are not necessarily errors, they're hardly silent, and if you don't 
want NANs, the standard mandates that there be a way to turn them off.



> [snip]
>> You'll note that, out of the box, numpy generates NANs:
>> 
>> >>> import numpy
>> >>> x = numpy.array([float(x) for x in range(5)]) x/x
>> Warning: invalid value encountered in divide array([ nan,   1.,   1.,  
>> 1.,   1.])
> 
> Steven, seriously I don't know what's going through your head.  I'm
> saying strict adherence to IEEE is not the best idea, and you cite the
> fact that a library tries to strictly adhere to IEEE as evidence that
> strictly adhering to IEEE is a good idea.  Beg the question much?

And I'm demonstrating that the people who do serious numeric work stick 
to the standard as much as possible. They do this because the standard is 
proven to be useful, otherwise they would abandon it, or start a new 
standard.


[...]
> It's clear tha IEEE's NaN handling is woefully out of place in the
> philosophy of Python, which tries to be newbie friendly and robust to
> errors; 

NANs are newbie friendly, and robust to errors.

You can't get more newbie friendly than Apple's Hypertalk, sadly 
abandoned. Among Mac users in the late 80s and 90s, Hypertalk, and its 
front end Hypercard, was like software Lego and BASIC rolled into one. 
And it supported NANs from day one.




-- 
Steven