Mark Dickinson <dicki...@gmail.com> added the comment:
Many thanks for reviewing, Stefan, and for the patch.
Here's an updated patch:
- specify 32-bit/64-bit C long rather than 32-bit/64-bit machine
- apply hash->hash_ fix to Python hash recipe
- use _PyHASH_MODULUS instead of _PyHASH_MASK throughout (this
was bugging me).
- reorganize the stdtypes doc entry slightly
- update against current svn, and remove outdated test_float tests
for the values of float('inf') and float('nan')
One unresolved issue: it would probably make sense to specify (publicly) a
hash algorithm for complex types, too, so that someone implementing e.g.
Gaussian integers can make their hash function agree with that for the complex
type where appropriate.
That hash algorithm would probably be as simple as:
hr = hash(x.real)
hi = hash(x.imag)
return <some suitably bit-mixing combination of hi and hr>
where the algorithm for the combination needs to be specified explicitly, and
any relevant parameters put into sys.hash_info.
(Unfortunately, -1 doesn't have square roots modulo the prime P used, else we
could do the cute thing and make use of a square root of -1 modulo P.)
Another tiny detail: I'm wondering whether hash(m/P) should care about the
sign of m: currently it doesn't, which means that the symmetry hash(-x) =
-hash(x) *almost* always holds for a rational x, but not always. An
almost-always-true symmetry seems like a recipe for hard-to-find bugs.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
