On Fri, Mar 19, 2010 at 1:17 PM, Case Vanhorsen <casevh@gmail.com> wrote:
On Fri, Mar 19, 2010 at 3:07 AM, Mark Dickinson <dickinsm@gmail.com> wrote:
On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson <dickinsm@gmail.com> wrote:
Making hashes of int, float, Decimal *and* Fraction all compatible with one another, efficient for ints and floats, and not grossly inefficient for Fractions and Decimals, is kinda hairy, though I have a couple of ideas of how it could be done.
To elaborate, here's a cute scheme for the above, which is actually remarkably close to what Python already does for ints and floats, and which doesn't require any of the numeric types to figure out whether it's exactly equal to an instance of some other numeric type.
Will this change the result of hashing a long? I know that both gmpy and SAGE use their own hash implementations for performance reasons. I understand that CPython's hash function is an implementation detail, but there are external modules that rely on the existing hash behavior.
Yes, it would change the hash of a long. What external modules are there that rely on existing hash behaviour? And exactly what behaviour do they rely on? Mark