homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: NaN comparison in Decimal broken
Type: Stage:
Components: Library (Lib) Versions: Python 2.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: tim.peters Nosy List: charlesmerriam, mark.dickinson, nmm, rhettinger, tim.peters
Priority: low Keywords:

Created on 2006年06月29日 16:19 by nmm, last changed 2022年04月11日 14:56 by admin. This issue is now closed.

Messages (7)
msg28971 - (view) Author: Nick Maclaren (nmm) Date: 2006年06月29日 16:19
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
msg28972 - (view) Author: Nick Maclaren (nmm) Date: 2006年07月13日 10:35
Logged In: YES 
user_id=42444
It's still there in Beta 2.
msg28973 - (view) Author: CharlesMerriam (charlesmerriam) Date: 2006年08月23日 08:43
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.
msg28974 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2007年01月06日 02:05
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?
msg59517 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008年01月08日 02:35
It seems likely that Decimal is going to grow rich comparisons anyway, 
either as a result of PEP 3141 or as a result of removal of __cmp__.
Given this, would there be any objections to making comparisons do the 
right thing (in the sense of IEEE-754) for NaNs?
msg61991 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008年02月02日 02:33
See issue #1979 for a possible fix.
msg62130 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008年02月07日 01:30
Fixed for Python 2.6 in r60630.
History
Date User Action Args
2022年04月11日 14:56:18adminsetgithub: 43573
2008年02月07日 01:30:06mark.dickinsonsetstatus: open -> closed
resolution: fixed
messages: + msg62130
2008年02月02日 02:33:08mark.dickinsonsetmessages: + msg61991
2008年01月08日 02:35:44mark.dickinsonsetnosy: + mark.dickinson
messages: + msg59517
2006年06月29日 16:19:46nmmcreate

AltStyle によって変換されたページ (->オリジナル) /