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

[Mark Dickinson]

On Sat, Mar 20, 2010 at 12:10 AM, Greg Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> Nick Coghlan wrote:
>>
>> Mark Dickinson wrote:
>
>> It seems to me that given the existing conflation of numeric equivalence
>> and containment testing, going the whole hog and fixing the set
>> membership problem for all of our rational types would be the right
>> thing to do.
>
> Isn't this only solving half the problem, though?

Yes.

> Even if
> you find that the hashes are equal, you still have to decide
> whether the values themselves are equal.

True.  The reason I was concentrating on the hashes is that it's not
immediately obvious that it's even *possible* to find a decent hash
function that's efficient to compute and gives equal results for
numerically equal inputs (regardless of type); this is especially true
if you don't want to significantly slow down the existing hashes for
int and float.  But once that problem is solved, it shouldn't be too
hard to implement all the comparisons.

It *is* kinda messy, because as far as I can see the oddities of the
various types mean that you end up producing specialized code for
comparing each pair of types (one block of code for float<->Fraction
comparisons, another for float<->Decimal, yet another for
Decimal<->Fraction, and so on), but it's doable.

Mark