float("nan") in set or as key

[Steven D'Aprano]

On Sat, 04 Jun 2011 00:29:10 +0100, Nobody wrote:

> If you're "fluent" in IEEE-754, then you won't find its behaviour
> unexpected. OTOH, if you are approach the issue without preconceptions,
> you're likely to notice that you effectively have one exception
> mechanism for floating-point and another for everything else.

Returning a sentinel meaning "an exceptional event occurred" is hardly 
unusual, even in Python. str.find() does is, as does re.search() and 
re.match().

In any case, nobody says that NANs should replace exceptions for floats, 
least of all the standard.


[...]
> As for IEEE-754 saying that it's [NAN == NAN] True: they only really
> had two choices: either it's True or it's False.

Incorrect. They could have specified that it was an error, like dividing 
by zero, but they didn't. Instead, the standard specifies that there are 
four mutually exclusive relationships possible:

greater than
less than
equal 
unordered

and that comparisons should either return a code identifying the 
relationship, or a True/False value. The standard allows for order 
comparisons less_than(x, y) etc. in both signalling and quiet forms.

See section 7.11 of 
http://www.validlab.com/754R/drafts/archive/2006-10-04.pdf

(the most recent draft of the 2008 standard I can find without paying for 
the official standard).


> NaNs provide "exceptions" even if the
> hardware or the language lacks them, but that falls down once you leave
> the scope of floating-point. It wouldn't have been within IEEE-754's
> ambit to declare that comparing NaNs should return NaB (Not A Boolean).

Of course it would have been. That's effectively what the standard 
actually does. Not "Not A Bool" per se, but comparisons can return 
"Unordered", or they can signal.



-- 
Steven