[Python-Dev] Decimal <-> float comparisons in py3k.

[Steven D'Aprano]

On Wed, 17 Mar 2010 10:01:12 am Guido van Rossum wrote:
> On Tue, Mar 16, 2010 at 2:32 PM, Steven D'Aprano <steve at pearwood.info> 
wrote:
> > But mixed arithmetic runs into the problem, what do you want the
> > result type to be? Given (say) decimal+float, returning either a
> > Decimal or a float will be the wrong thing to do some of the time,
> > so better to prohibit mixed arithmetic and let folks handle their
> > own conversions. So +1 on continuing to prohibit mixed arithmetic.
>
> I'm not disagreeing, but I really wonder, what is the value of
> supporting mixed comparisons then? Just because you *can* assign a
> meaning to it doesn't mean you should.

Any mixed comparison with floats is already risky:

>>> 1e20 + 1e4 == 10**20 + 10**4
False

but we allow them anyway because they're too useful and too obvious not 
to. The problems with (say) floating point equality are far too well 
known to need me give examples, but I will anyway *wink*:

>>> 1.3 == 3.7 - 2.4
False

but we allow it anyway, partly from tradition ("floats have always been 
like that") and partly because, frankly, laziness is a virtue. It would 
be painful not to be able to say (e.g.):

>>> 1.25 == 3.75 - 2.5
True
>>> 10.0 > 1
True

My defence of mixed comparisons is the same. If I'm doing serious maths 
work, then I'm going to be comparing numbers carefully, and not just 
tossing a comparison operator between them. But for simple 
calculations, or using the interactive interpreter as a calculator, or 
if I need to sort a list of mixed numbers without caring whether they 
are ints or floats or Decimals, laziness is a virtue. If your needs for 
accuracy aren't high, you can go far by comparing floats with ==. Why 
shouldn't the same apply to mixed floats and Decimals?

Having said all that, I've just re-read the PEP, and spotted a fly in 
the ointment... hash.

If we allow Decimals to compare equal to floats, that presumably implies 
that they need to hash equal. That may be simple enough for integer 
valued floats, but what non-integer values?




-- 
Steven D'Aprano