[Python-Dev] Decimal <-> float comparisons in py3k. (original) (raw)
Mark Dickinson dickinsm at gmail.com
Sat Mar 20 12:16:39 CET 2010
- Previous message: [Python-Dev] Decimal <-> float comparisons in py3k.
- Next message: [Python-Dev] Decimal <-> float comparisons in py3k.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Decimal <-> float comparisons in py3k.
- Next message: [Python-Dev] Decimal <-> float comparisons in py3k.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]