Mark Dickinson <dicki...@gmail.com> added the comment: > 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.
Seems reasonable; I'm tempted to call the constant it hash_info.imaginary and _PyHASH_IMAGINARY, though. :) There's also an implicit parameter in this algorithm, namely the size of a C long; I think this should go into sys.hash_info, too. complex_hash does need fixing in one respect: it currently depends on signed overflow wrapping modulo 2**BIT_IN_LONG, but that's undefined behaviour; it should use unsigned arithmetic instead. > I think hash(m/P) should preserve sign. It just seems more symmetrical. :) Agreed. Along similar lines, I think I'm also going to get rid of _PyHASH_NINF and just use -PyHASH_INF instead. ---------- _______________________________________ 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
