Message 103800 - Python tracker

➜

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	casevh
Recipients	Rhamphoryncus, casevh, eric.smith, mark.dickinson, rhettinger, skrah
Date	2010-04-21.03:23:04
SpamBayes Score	1.0326022e-05
Marked as misclassified	No
Message-id	<1271820186.61.0.848293319345.issue8188@psf.upfronthosting.co.za>
In-reply-to

Content
I've spent some time working through the new hash function by re-implementing it for gmpy. Very elegant design. I like _PyHASH_MODULUS better, too. Regarding a hash function for complex types, I think documenting the existing behavior for PyComplex is sufficient. The magic number 1000003 could be documented in hash_info as 'multiplier' and _PyHASH_MULTIPLIER. The same constant, but a different algorithm, is also used when hashing a tuple. I think hash(m/P) should preserve sign. It just seems more symmetrical. :)

I've spent some time working through the new hash function by re-implementing it for gmpy. Very elegant design.

I like _PyHASH_MODULUS better, too.

Regarding a hash function for complex types, I think documenting the existing behavior for PyComplex is sufficient. The magic number 1000003 could be documented in hash_info as 'multiplier' and _PyHASH_MULTIPLIER. The same constant, but a different algorithm, is also used when hashing a tuple.

I think hash(m/P) should preserve sign. It just seems more symmetrical. :)

History
Date	User	Action	Args
2010-04-21 03:23:06	casevh	set	recipients: + casevh, rhettinger, mark.dickinson, Rhamphoryncus, eric.smith, skrah
2010-04-21 03:23:06	casevh	set	messageid: <1271820186.61.0.848293319345.issue8188@psf.upfronthosting.co.za>
2010-04-21 03:23:04	casevh	link	issue8188 messages
2010-04-21 03:23:04	casevh	create