float("nan") in set or as key
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Mon May 30 19:22:01 EDT 2011
On Mon, 30 May 2011 19:58:35 +0000, Chris Torek wrote:
> In article <4de3358b$0$29990$c3e8da3$5496439d at news.astraweb.com> Steven
> D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
>>Better than a float method is a function which takes any number as
>>argument:
>>
>>>>> import math, fractions, decimal
>>>>> math.isnan(fractions.Fraction(2, 3))
>>False
>>>>> math.isnan(decimal.Decimal('nan'))
>>True
>
> Ah, apparently someone's been using Larry Wall's time machine. :-)
He has one too? Just like Guido van Rossum.
> I should have looked at documentation. In my case, though:
>
> $ python
> Python 2.5.1 (r251:54863, Dec 16 2010, 14:12:43) [GCC 4.0.1 (Apple
> Inc. build 5465)] on darwin Type "help", "copyright", "credits" or
> "license" for more information.
Python 2.5 is two major releases behind! I feel your pain, though,
because 2.5 is the system python on my desktop as well. (And 2.4 is the
system python on my server, ouch!)
You should consider installing 2.7 and/or 3.2 in parallel with the system
python.
> Would it be appropriate to have isnan() methods for Fraction, Decimal,
> and complex, so that you do not need to worry about whether to use
> math.isnan() vs cmath.isnan()?
Probably not. From a purely object-oriented, Java-esque viewpoint, yes,
all number types should support isnan and isinf methods, but Python uses
a more mixed style, and a function that accepts multiple types is
appropriate.
Unless you're using complex numbers, you don't need to care about complex
numbers. *wink* Hence for "normal" numeric use, stick to the math module.
If you do need complex numbers, cmath.isnan works perfectly fine with non-
complex arguments:
>>> cmath.isnan(42)
False
>>> cmath.isnan(float('nan'))
True
--
Steven
More information about the Python-list
mailing list