On Sun, Nov 8, 2009 at 4:26 PM, Stefan Krah <stefan-use...@bytereef.org> wrote: > Hi, > > in a (misguided) bugreport (http://bugs.python.org/issue7279) I was > questioning the reasons for allowing NaN comparisons with == and != > rather than raising InvalidOperation.
Some quick recent history: For reference, the current behaviour dates from r60630. Before this, comparisons involving nans behaved even less coherently. See http://bugs.python.org/issue1979 for details. Apart from Python's use of __eq__, the other motivation for the current behaviour comes from the IEEE 854 standard; given the absence of helpful information in the Decimal standard, IEEE 854 is an obvious next place to look. There's an unofficial copy of the standard available at: http://754r.ucbtest.org/standards/854.pdf Section 5.7 describes twenty-six(!) distinct comparison operators. So it's not immediately clear which of those twenty-six comparison operators each of Python's six comparison operators should map to. However, in the standard, the first six operations in the table are somewhat distinguished: they're the ones that are marked as corresponding to the usual mathematical operations, and to Fortran's usual comparison operators (.EQ., etc.). Given this, and given that this behaviour seemed to fit well with Python's needs for __eq__, it seemed to make sense at the time to map Python's six operators to the first 6 operators in table 3. > I think two main issues emerge from the brief discussion: > > 1. Should the comparison operators follow the 'compare' function > from the standard? That's a possibility. But see below. > 2. What is the use of == and != outside the decimal scope? > > Mark mentions that Python uses == to test for set and dict memberships, > but that you cannot put decimal NaNs into sets: > > 'TypeError: Cannot hash a NaN value' > > > I want to add that Decimal('NaN') == Decimal('NaN') gives False, which > should somewhat limit the uses of == for NaNs outside the decimal realm > anyway. > > > Are there cases where == and != are actually needed to give a result > for NaNs? Well, when running in some form of 'non-stop' mode, where (quiet) NaN results are supposed to be propagated to the end of a computation, you certainly want equality comparisons with nan just to silently return false. E.g., in code like: if x == 0: <deal with zero special case> else: <usual algorithm> nans should just end up in the second branch, without the programmer having had to think about it too hard. So I think comparisons with nans should always return either True or False when InvalidOperation is not trapped. The question is whether comparisons should always signal when InvalidOperation is trapped (which is what happens with the default context). I'm -0.5 on changing the current behaviour: it may not be exactly right, and if I were implementing Decimal from scratch I might well do things differently, but I don't think it's terribly wrong either. While not based on the Decimal standard itself, it's based on the next most closely- related standard. It works with Python's needs for __eq__ and __ne__. And it's already out there in Python 2.6; making minute adjustments to existing behaviour without a good reason seems like asking for trouble. Mark _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
