float("nan") in set or as key

[Grant Edwards]

On 2011-06-03, Nobody <nobody at nowhere.com> wrote:

>>> This would produce the same end result as raising an exception
>>> immediately, but would reduce the number of isnan() tests.
>> 
>> I've never found the number of isnan() checks in my code to be an
>> issue -- there just arent that many of them, and when they are there,
>> it provides an easy to read and easy to maintain way to handle things.
>
> I think that you misunderstood. What I was saying here was that, if you
> wanted exception-on-NaN behaviour from Python, the interpreter wouldn't
> need to call isnan() on every value received from the FPU, but rely upon
> NaN-propagation and only call it at places where a NaN might disappear
> (e.g. comparisons).

Ideed, I did misunderstand.  I thought you were talking about a
the value of reducing the number of isnan() tests in user application
code.

>>> I mean undefined, in the sense that 0/0 is undefined
>> 
>> But 0.0/0.0 _is_ defined.  It's NaN.  ;)
>
> Mathematically, it's undefined.

True, but we must be careful not to confuse math and scientific
calculation using fixed-length binary floting point.

>> IMHO, that's a bug.  IEEE-754 states explicit that 0.0/0.0 is NaN.
>> Pythons claims it implements IEEE-754.  Python got it wrong.
>
> But then IEEE-754 considers integers and floats to be completely
> different beasts, while Python makes some effort to maintain a
> unified "numeric" interface. If you really want IEEE-754
> to-the-letter, that's undesirable, although I'd question the choice
> of Python in such situations.

Python's minor issues with IEEE-754 are far outweighed by advantages
in other areas. :)

>>> If anything, it has proven to be a major nuisance. It takes a lot of
>>> effort to create (or even specify) code which does the right thing in
>>> the presence of NaNs.
>> 
>> That's not been my experience.  NaNs save a _huge_ amount of effort
>> compared to having to pass value+status info around throughout
>> complex caclulations.
>
> That's what exceptions are for. NaNs probably save a huge amount of
> effort in languages which lack exceptions, but that isn't applicable
> to Python.

How do you obtain using exceptions a behavior that's the same as with
quiet NaNs?

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

It was an attempt to illustate the overstatement to which it was a
reply.

-- 
Grant Edwards               grant.b.edwards        Yow! You should all JUMP
                                  at               UP AND DOWN for TWO HOURS
                              gmail.com            while I decide on a NEW
                                                   CAREER!!