float("nan") in set or as key

[Carl Banks]

On Wednesday, June 1, 2011 5:53:26 PM UTC-7, Steven D'Aprano wrote:
> On Tue, 31 May 2011 19:45:01 -0700, Carl Banks wrote:
> 
> > 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.
> 
> 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.  Therefore the fact that NaN is in IEEE is not any evidence that NaN is a good idea.

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.

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.


> NANs weren't invented as an alternative for 
> exceptions, but because exceptions are usually the WRONG THING in serious 
> numeric work.
> 
> Note the "usually". For those times where you do want to interrupt a 
> calculation just because of an invalid operation, the standard allows you 
> to set a trap and raise an exception.

I don't want to get into an argument over best practices in serious numerical programming, so let's just agree with this point for argument's sake.

Here's the problem: Python is not for serious numerical programming.  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.

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.


[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?


> The IEEE standard supports both use-cases: those who want exceptions to 
> bail out early, and those who want NANs so the calculation can continue. 
> This is a good thing. Failing to support the standard is a bad thing. 
> Despite your opinion, it is anything but obsolete.

There are all kinds of good reasons to go against standards.  "Failing to support the standard is a bad thing" are the words of a fool.  A wise person considers the cost of breaking the standard versus the benefit got.

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; and Python has no real business trying to perform serious numerical work where (ostensibly) NaNs might find a use.  Therefore, the cost of breaking standard is small, but the benefit significant, so Python would be very wise to break with IEEE in the handling of NaNs.


Carl Banks