float("nan") in set or as key

[Carl Banks]

On Sunday, May 29, 2011 4:31:19 PM UTC-7, Steven D'Aprano wrote:
> On Sun, 29 May 2011 22:19:49 +0100, Nobody wrote:
> 
> > On Sun, 29 May 2011 10:29:28 +0000, Steven D'Aprano wrote:
> > 
> >>>     The correct answer to "nan == nan" is to raise an exception,
> >>>     because
> >>> you have asked a question for which the answer is nether True nor
> >>> False.
> >> 
> >> Wrong.
> > 
> > That's overstating it. There's a good argument to be made for raising an
> > exception. 
> 
> If so, I've never heard it, and I cannot imagine what such a good 
> argument would be. Please give it.

Floating point arithmetic evolved more or less on languages like Fortran where things like exceptions were unheard of, and defining NaN != NaN was a bad trick they chose for testing against NaN for lack of a better way.

If exceptions had commonly existed in that environment there's no chance they would have chosen that behavior; 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, but given that Python has trailblazed a path of correcting arcane mathematical behavior, I definitely see an argument that Python should do the same for NaN, and if it were done Python would be a better language.


Carl Banks