Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #74209 > unrolled thread

Re: NaN comparisons - Call For Anecdotes

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: NaN comparisons - Call For Anecdotes Ian Kelly <ian.g.kelly@gmail.com> - 2014-07-08 13:57 -0600
    Re: NaN comparisons - Call For Anecdotes Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-09 01:04 +0000

#74209 — Re: NaN comparisons - Call For Anecdotes

On Tue, Jul 8, 2014 at 12:54 PM, Anders J. Munch <2014@jmunch.dk> wrote:
>
> Ian Kelly wrote:
>>
>> As far as I know nothing changed between 2.4 and 2.7 in this regard.
>> Python has always had NaN compare unequal to everything, per the
>> standard.
>
> It might have been platform-specific in 2.4.

I doubt it, but okay, which platform?

>> Okay, here's your problem: there isn't just one binary representation
>> for NaN.
>
> I'm fully aware of that. Whether NaN's are one equivalence class or several
> is not the issue. What matters is the integrity of the equivalence relation.

I have some bad news for you.  This is on Python 2.7.6:

>>> from decimal import Decimal
>>> from fractions import Fraction
>>> Decimal(2) == 2
True
>>> 2 == Fraction(2)
True
>>> Decimal(2) == Fraction(2)
False

I'm not sure exactly when this bug was fixed, but it works as expected in 3.4.0.


>> Following the standard isn't a good reason itself?
>
> If a standard tells you to jump of a cliff...

So I don't know of a good use case for nan != nan in Python (but
really I'm not the one to ask), but I do know of use cases in other
scenarios.  On platforms that don't provide an isnan() function, the
only convenient and efficient way to test for nan is by testing
reflexivity: x != x.

Following the standard means that any algorithm that uses this trick
can (in theory) be implemented in Python without changes.

[toc] | [next] | [standalone]

#74222

On Tue, 08 Jul 2014 13:57:30 -0600, Ian Kelly wrote:

>>>> Decimal(2) == Fraction(2)
> False
> 
> I'm not sure exactly when this bug was fixed, but it works as expected
> in 3.4.0.

It isn't a bug, it's a missing feature. The problem is that in Python 
2.7, neither Decimal nor Fraction are aware of the other:

py> Decimal(2).__eq__(Fraction(2))
NotImplemented
py> Fraction(2).__eq__(Decimal(2))
NotImplemented


The obvious, but wrong, solution is to coerce both into floats:

py> a = Decimal("2.000000000000000000000000000001")
py> b = Fraction(2) - Fraction(1, 2)**100
py> a > 2 > b  # a and b are certainly not equal
True
py> float(a) == float(b)
True

Some time by Python 3.3, Decimal appears to have become aware of how to 
compare exactly with Fraction.


-- 
Steven

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web