Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!selfless.tophat.at!news.glorb.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!spln!extra.newsguy.com!newsp.newsguy.com!not-for-mail
From: Chris Torek <nospam@torek.net>
Newsgroups: comp.lang.python
Subject: Re: float("nan") in set or as key
Date: 30 May 2011 04:29:19 GMT
Organization: None of the Above
Lines: 43
Message-ID: <irv6ev01jht@news1.newsguy.com>
References: <271acea3-c38f-4123-9038-e348fb841971@glegroupsg2000goo.googlegroups.com> <4de31635$0$29990$c3e8da3$5496439d@news.astraweb.com>
NNTP-Posting-Host: p604ef3e733afca5ae57555d09efc739e612a0a4e3164cd00.newsdawg.com
X-Newsreader: trn 4.0-test76 (Apr 2, 2001)
Originator: torek@elf.torek.net (Chris Torek)
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:6624

In article <4de31635$0$29990$c3e8da3$5496439d@news.astraweb.com>,
Steven D'Aprano  <steve+comp.lang.python@pearwood.info> wrote:
>That's also completely wrong. The correct way to test for a NAN is with 
>the IEEE-mandated function isnan(). The NAN != NAN trick is exactly that, 
>a trick, used by programmers when their language or compiler doesn't 
>support isnan().

Perhaps it would be reasonable to be able to do:

    x.isnan()

when x is a float.

>Without support for isinf(), identifying an INF is just as hard as 
>identifying an NAN, and yet their behaviour under equality is the 
>complete opposite:
>
>>>> inf = float('inf')
>>>> inf == inf
>True

Fortunately:

    def isnan(x):
        return x != x
    _inf = float("inf")
    def isinf(x):
        return x == _inf
    del _inf

both do the trick here.

I would like to have both modes (non-exception-ing and exception-ing)
of IEEE-style float available in Python, and am not too picky about
how they would be implemented or which one would be the default.
Python could also paper over the brokenness of various actual
implementations (where signalling vs quiet NaNs, and so on, do not
quite work right in all cases), with some performance penalty on
non-conformant hardware.
-- 
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