On 3/18/2010 5:23 AM, Steven D'Aprano wrote:
On Thu, 18 Mar 2010 08:58:25 am Raymond Hettinger wrote:
On Mar 17, 2010, at 1:59 PM, Steven D'Aprano wrote:
On Thu, 18 Mar 2010 07:44:21 am Raymond Hettinger wrote:
The spectrum of options from worst to best is
1) compare but give the wrong answer
2) compare but give the right answer
3) refuse to compare.
Why is 3 the best? If there is a right answer to give, surely
giving the right answer it is better than not?
From the early days of the decimal module,
we've thought that mixed float-decimal operations
are 1) a bit perilous and 2) have few, if any good
use cases.
When it comes to *arithmetic* operations, I agree. Is there anyone on
python-dev willing to argue the case for allowing implicit mixed
float/Decimal arithmetic operations? The arguments in the PEP seem
pretty convincing to me, and I'm not suggesting we change that.
But comparison operations are different. For starters, you don't need to
worry about whether to return a float or a Decimal, because you always
get a bool. In theory, both Decimals and floats are representations of
the same underlying thing, namely real numbers, and it seems strange to
me that I can't ask whether two such real numbers are equal just
because their storage implementation is different.
I can see three reasonable reasons for avoiding mixed comparisons:
(1) To avoid confusing float-naive users (but they're confused by pure
float comparisons too).
(2) To avoid mixed arithmetic operations (but comparisons aren't
arithmetic).
(3) If Decimals and floats compare equal, they must hash equal, and
currently they don't (but Mark Dickinson thinks he has a solution for
that).
Accordingly, any mixed operations should be explicit
rather than implicit:
Decimal('1.1') + Decimal.from_float(2.2)
is better than:
Decimal('1.1') + 2.2
Agreed. The user should explicitly choose whether they want a float
answer or a Decimal answer.
To help the user avoid confusion, we flag the latter with a
TypeError: unsupported operand type(s) for +: 'Decimal' and 'float'.
Unfortunately, in Py2.x, implicit mixed comparisons do not
raise an exception, and instead will silently fail by giving
an incorrect answer:
>>> Decimal('1.1')< 2.2
False
That is clearly the wrong thing to do.
Do you envisage any problems from allowing this instead?
Decimal('1.1')< 2.2
True
Yes.
As any non-naïve float user is aware, the proper form of float
comparisons is not to use < or > or == or !=, but rather, instead of
using < (to follow along with your example), one should use:
Decimal('1.1') - 2.2 < epsilon
However, while even this is only useful in certain circumstances as a
gross simplification [1], it immediately shows the need to do mixed
arithmetic to produce (sometimes) correct results. More correct
comparisons require much more code (even the 20-line C code in [1],
which understands the float format to some extent, admits to being
deficient in some circumstances).
For all the reasons that mixed decimal and float arithmetic is bad,
mixed decimal and float comparisons are also bad. To do proper
comparisons, you need to know the number of significant digits of both
numbers, and the precision and numeric ranges being dealt with by the
application.
For the single purpose of sorting, one could make an argument that not
knowing the significant digits, precision, and numeric ranges, that the
sort would probably produce results where floats and decimals that
should compare equal would be clustered similarly as they would if the
significant digits, precision, and numeric ranges were known, and that
would probably be close to truth, but only if the decimal vs float key
were the last in the composite sort key. I don't think Python informs
its comparison operations that it is being used as part of a sort, nor
would there be a way for user-written sorts to inform the comparison
operations of that fact.
Seems like it would be better to raise an exception, and in the
documentation for the exception point out that turning off the exception
(if it should be decided that that should be possible, which could be
good for compatibility), would regress to the current behavior, which
doesn't sort numerically, but by type.
[1]
http://www.cprogramming.com/tutorial/floating_point/understanding_floating_point_representation.html
Glenn
_______________________________________________
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
