float("nan") in set or as key

Chris Torek nospam at torek.net
Fri Jun 3 13:52:24 EDT 2011


>On 2011-06-02, Nobody <nobody at nowhere.com> wrote:
>> (I note that Python actually raises an exception for "0.0/0.0").

In article <isasfm$inl$1 at reader1.panix.com>
Grant Edwards  <invalid at invalid.invalid> wrote:
>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.

Indeed -- or at least, inconsistent.  (Again I would not mind at
all if Python had "raise exception on NaN-result" mode *as well
as* "quietly make NaN", perhaps using signalling vs quiet NaN to
tell them apart in most cases, plus some sort of floating-point
context control, for instance.)

>> Also, note that the "convenience" of NaN (e.g. not propagating from
>> the untaken branch of a conditional) is only available for
>> floating-point types. If it's such a good idea, why don't we have it
>> for other types?

Mostly because for integers it's "too late" and there is no standard
for it.  For others, well:

    >>> import decimal
    >>> decimal.Decimal('nan')
    Decimal("NaN")
    >>> _ + 1
    Decimal("NaN")
    >>> decimal.setcontext(decimal.ExtendedContext)
    >>> print decimal.Decimal(1) / 0
    Infinity
    >>> [etc]

(Note that you have to set the decimal context to one that does
not produce a zero-divide exception, such as the pre-loaded
decimal.ExtendedContext.  On my one Python 2.7 system -- all the
rest are earlier versions, with 2.5 the highest I can count on,
and that only by upgrading it on the really old work systems --
I note that fractions.Fraction(0,0) raises a ZeroDivisionError,
and there is no fractions.ExtendedContext or similar.)

>> The definition is entirely arbitrary.
>
>I don't agree, but even if was entirely arbitrary, that doesn't make
>the decision meaningless.  IEEE-754 says it's True, and standards
>compliance is valuable.  Each country's decision to drive on the
>right/left side of the road is entire arbitrary, but once decided
>there's a huge benefit to everybody following the rule.

This analogy perhaps works better than expected.  Whenever I swap
between Oz or NZ and the US-of-A, I have a brief mental clash that,
if I am not careful, could result in various bad things. :-)
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: gmail (figure it out)      http://web.torek.net/torek/index.html



More information about the Python-list mailing list