Mark Dickinson dicki...@gmail.com added the comment:
Committed the Decimal-to-Fraction comparisons in r81893. All numeric types
should now compare nicely with each other.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8188
Mark Dickinson dicki...@gmail.com added the comment:
Committed the hash changes in r81486. This commit just changes the method for
computing hash values; it doesn't include the changes to the decimal module
that make Decimal instances comparable with Fraction instances.
--
Mark Dickinson dicki...@gmail.com added the comment:
Updated patch:
- make hash(m/P) preserve sign, as discussed earlier
- add details for computing the hash of a complex number
- reorganize sys.hash_info
- drop sys.hash_info.bits (the exponent of the Mersenne prime);
it's not
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 103
could be documented in hash_info as 'multiplier' and _PyHASH_MULTIPLIER.
Seems reasonable;
Case Van Horsen cas...@gmail.com added the comment:
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
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
Changes by Mark Dickinson dicki...@gmail.com:
--
assignee: - mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8188
___
___
Mark Dickinson dicki...@gmail.com added the comment:
... and here's the actual patch... Forget my own head next. :)
--
Added file: http://bugs.python.org/file16907/numeric_hash7.patch
___
Python tracker rep...@bugs.python.org
Changes by Mark Dickinson dicki...@gmail.com:
--
priority: - normal
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8188
___
___
Python-bugs-list
Stefan Krah stefan-use...@bytereef.org added the comment:
I've finished reviewing the patch and I think it's quite ready to be
applied.
The documentation in stdtypes.rst says that P = 2**61-1 on 64-bit
machines. This should be changed to reflect the fact that actually
sizeof long is the
Mark Dickinson dicki...@gmail.com added the comment:
New patch:
- document and test sys.hash_info
- document numeric hash definition (in Doc/library/stdtypes.rst; I'm
not sure whether this is the best place for it)
- document Decimal change (Decimal instances are now comparable
with
Mark Dickinson dicki...@gmail.com added the comment:
I've refreshed the Rietveld patch as well:
http://codereview.appspot.com/660042
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8188
Stefan Krah stefan-use...@bytereef.org added the comment:
Mark, very nice concept! - I'm just starting to review the patch, but I
think the unsigned longs in_Py_HashDouble() and long_hash() should be
uint64_t on a 64-bit OS.
For instance, now on Windows 64-bit:
hash(2**61-1)
1073741823
Stefan Krah stefan-use...@bytereef.org added the comment:
Actually the current long_hash() is affected as well. On Windows 64-bit:
hash(2**31)
-2147483648
hash(2**32)
1
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8188
Mark Dickinson dicki...@gmail.com added the comment:
Yes, hash values are C longs, regardless of platform. I think that's probably
too ingrained to consider changing it (we'd have to change hashes of all the
non-numeric types, too).
--
___
Python
Mark Dickinson dicki...@gmail.com added the comment:
Here's a version of the patch that adds exact comparisons between the various
numeric types. The only slightly tricky comparison is the Fraction - Decimal
one: an obvious strategy is to convert the Decimal exactly to a Fraction and
then
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8188
___
___
Python-bugs-list
Mark Dickinson dicki...@gmail.com added the comment:
Another update, partly to address comments raised by Guido on Rietveld. I'll
upload these changes to Rietveld later today.
- rename sys._hash_info to sys.hash_info and make it public rather than
private (it still needs docs somewhere)
-
Mark Dickinson dicki...@gmail.com added the comment:
Updated patch:
- put hash parameters into pyport.h, to avoid repetition; make them
available to Python code via a private attribute sys._hash_info.
- use a modulus of 2**61-1 on systems where SIZEOF_LONG = 8, and
a modulus of 2**31
New submission from Mark Dickinson dicki...@gmail.com:
Here's a patch that makes hash(x) == hash(y) for any numeric types (int, float,
complex, Decimal, Fraction, bool) when x and y are numerically equal.
This is a prerequisite for making all numeric types accurately comparable with
each
Mark Dickinson dicki...@gmail.com added the comment:
Uploaded to Rietveld:
http://codereview.appspot.com/660042
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8188
___
Mark Dickinson dicki...@gmail.com added the comment:
Updated patch, with a bit of cleanup and some comments describing the hashing
strategy; I'll update the Rietveld issue as well.
--
Added file: http://bugs.python.org/file16606/numeric_hash2.patch
Changes by Mark Dickinson dicki...@gmail.com:
Removed file: http://bugs.python.org/file16606/numeric_hash2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8188
___
Mark Dickinson dicki...@gmail.com added the comment:
Whoops; that patch included some accidental Lib/test/test_decimal changes.
Here's the correct patch.
--
Added file: http://bugs.python.org/file16607/numeric_hash2.patch
___
Python tracker
Adam Olsen rha...@gmail.com added the comment:
Why aren't you using 64-bit hashes on 64-bit architectures?
--
nosy: +Rhamphoryncus
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8188
___
Mark Dickinson dicki...@gmail.com added the comment:
Why aren't you using 64-bit hashes on 64-bit architectures?
Mostly because I haven't got around to putting that in yet. :)
Ideal would be to use _PyHASH_BITS=61 for 64-bit machines, throughout.
--
Adam Olsen rha...@gmail.com added the comment:
I assume you mean 63. ;)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8188
___
___
Mark Dickinson dicki...@gmail.com added the comment:
No, I mean 61. 2**61 - 1 is prime; 2**63-1 is not. (So 2 bits of the hash
get wasted, but that's not a big deal, especially since they're the high-end
bits and Python mostly cares about the lower-order bits.)
--
Mark Dickinson dicki...@gmail.com added the comment:
Restore tests accidentally omitted from second patch.
--
Added file: http://bugs.python.org/file16608/numeric_hash2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8188
Changes by Mark Dickinson dicki...@gmail.com:
Removed file: http://bugs.python.org/file16607/numeric_hash2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8188
___
Changes by Eric Smith e...@trueblade.com:
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8188
___
___
Python-bugs-list mailing
31 matches
Mail list logo
