What steps will reproduce the problem? 1. Run program gmpy_test.py in a 64-bit environment.

Method test_string_keys creates mpz objects from strings and uses them as dictionary keys.

Method test_long_keys does the same thing except the strings are cast to longs when creating the mpz objects.

Method test_int_keys uses ints (rather than longs or strings).

What is the expected output? What do you see instead? Output should have only "get ok" and "set ok" lines. There should not be any "get error" or "set error" lines.

What version of the product are you using? On what operating system? gmpy-1.02 on a 64-bit gentoo system

Please provide any additional information below. Creating mpz objects from strings and longs (with certain values) creates objects that cause exceptions when used as dictionary keys. Creating mpz objects using the same values (cast as ints) works fine.

Attached file gmpy_testv1-02.out shows the output.

Looking at gmpy.c, the hash functions all return longs. In a 32-bit environment, ints and longs are both 32 bits wide. In a 64-bit environment, ints are 32 bits wide and longs are 64 bits wide. It seems that python expects 32 bit ints for hash keys.

Attached patch file patch.64bit.txt changes the return types for the hash functions from long to int. Using gmpy built with this patch fixes the key errors (as shown in attached file gmpy_test.v1-02-fix.out).

Since the gmpy_test.py file is empty, I can't recreate the original issue. I think the correct solution is to a long for the hash. Using the attached patch, I tested a wide variety of values and verified that hash(long) always equaled hash(mpz).

casevh

Here's gmpy_test.py

I've run gmpy_test.py with gmpy.c(r17) and my version. There are failures with r17 and no failures with my version. The attached file shows runs (with both versions) as well as the output of "svn diff", "setup.py build", and "setup.py install"

Thank you for gmpy_test.py. I runs successfully with r18.

Your patch runs gmpy_test.py successfully but breaks the following:

import gmpy hash(long('12345678901234567890')) -6101065172474983726 hash(gmpy.mpz('1234567901234567890')) 338664146

At least on my system, hash appears to be a 64-bit value.

Can you test r18?

casevh

I can duplicate your results for hash(long()) and hash(gmpy.mpz()) for my patch. However running R18 produces -6101065172474983726 and 1234567901234567890.

* R18 *

Python 2.5.2 (r252:60911, May 16 2008, 23:11:42) [GCC 4.1.2 (Gentoo 4.1.2 p1.1)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

import gmpy print hash(long('12345678901234567890'))
-6101065172474983726 print hash(gmpy.mpz('1234567901234567890'))
1234567901234567890

* My Patch * Python 2.5.2 (r252:60911, May 16 2008, 23:11:42) [GCC 4.1.2 (Gentoo 4.1.2 p1.1)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

import gmpy print hash(long('12345678901234567890'))
-6101065172474983726 print hash(gmpy.mpz('1234567901234567890'))
338664146

hash(gmpy.mpz('1234567901234567890')) is missing an "8".

Since your hash values match mine, I'll mark this issue as fixed.

Thanks for the bug report.

casevh

Thanks for the fix!