[ python-Bugs-1514428 ] NaN comparison in Decimal broken

[SourceForge.net]

Bugs item #1514428, was opened at 2006-06-29 11:19
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514428&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 4
Private: No
Submitted By: Nick Maclaren (nmm)
Assigned to: Tim Peters (tim_one)
Summary: NaN comparison in Decimal broken

Initial Comment:
Methinks this is a bit off :-)  True should be False.


Python 2.5b1 (trunk:47059, Jun 29 2006, 14:26:46)
[GCC 4.1.0 (SUSE Linux)] on linux2
>>> import decimal
>>> d = decimal.Decimal
>>> inf = d("inf")
>>> nan = d("nan")
>>> nan > inf
True
>>> nan < inf
False
>>> inf > nan
True
>>> inf < nan
False
b

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-05 21:05

Message:
Logged In: YES 
user_id=80475
Originator: NO

The Decimal Arithmetic Specification says that NaN comparisons should
return NaN.  The decimal module correctly implements this through the
compare() method:

    >>> nan.compare(nan)
    Decimal('NaN')

Since python's < and > operators return a boolean result, the standard is
silent on what should be done.  The current implementation uses the __cmp__
method which can only return -1, 0, or 1, so there is not a direct way to
make both < and > both return False.

If you want to go beyond the standard and have both < and > return False
for all NaN comparisons, then the __cmp__ implementation would need to be
replaced with rich comparisons.  I'm not sure that this is desirable.  IMO,
that would be no better than the current arbitrary choice where all
comparisons involving NaN report self > other.  If someone has an
application that would be harmed by the current implementation, then it
should almost certainly be use the standard compliant compare() method
instead of the boolean < and > operators.

Tim, what say you?

----------------------------------------------------------------------

Comment By: CharlesMerriam (charlesmerriam)
Date: 2006-08-23 03:43

Message:
Logged In: YES 
user_id=1581732

More specifically, any comparison with a NaN should equal
False, even inf, per IEEE 754.  A good starting point to
convince oneself of this is http://en.wikipedia.org/wiki/NaN.


----------------------------------------------------------------------

Comment By: Nick Maclaren (nmm)
Date: 2006-07-13 05:35

Message:
Logged In: YES 
user_id=42444

It's still there in Beta 2.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514428&group_id=5470