This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients Rhamphoryncus, eric.smith, mark.dickinson, rhettinger, skrah
Date 2010-04-13.10:37:32
SpamBayes Score 5.8375527e-13
Marked as misclassified No
Message-id <>
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.
Date User Action Args
2010-04-13 10:37:35mark.dickinsonsetrecipients: + mark.dickinson, rhettinger, Rhamphoryncus, eric.smith, skrah
2010-04-13 10:37:35mark.dickinsonsetmessageid: <>
2010-04-13 10:37:33mark.dickinsonlinkissue8188 messages
2010-04-13 10:37:32mark.dickinsoncreate