[Python-Dev] Decimal <-> float comparisons in py3k. (original) (raw)
Case Vanhorsen casevh at gmail.com
Sat Mar 20 18:47:40 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 10:05 AM, Mark Dickinson <dickinsm at gmail.com> wrote:
On Sat, Mar 20, 2010 at 3:17 PM, Case Vanhorsen <casevh at gmail.com> wrote:
On Sat, Mar 20, 2010 at 4:06 AM, Mark Dickinson <dickinsm at gmail.com> wrote:
What external modules are there that rely on existing hash behaviour?
I'm only aware of gmpy and SAGE.
And exactly what behaviour do they rely on? Instead of calculating hash(long(mpz)), they calculate hash(mpz) directly. It avoids creation of a temporary object that could be quite large and is faster than the two-step process. I would need to modify the code so that it continues to produce the same result. Does gmpy only do this for Python 2.6? Or does it use different algorithms for 2.4/2.5 and 2.6? As far as I can tell, there was no reasonable way to compute longhash directly at all before the algorithm was changed for 2.6, unless you imitate exactly what Python was doing (break up into 15-bit pieces, and do all the rotation and addition exactly the same way), in which case you might as well be calling longhash directly. Mark
It does the later: it converts from GMP's internal format to CPython's long format and calculates the hash along the way. I may (should :) ) revert back to converting to long and then calling long_hash. The majority of the speed increase came from the conversion improvements, not the hash calculation.
I am in favor of any change that makes 2.7 and 3.2 behave the same.
casevh
- 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 ]