Problem using mpz objects as dictionary keys

[GoogleCodeExporter]

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).

Original issue reported on code.google.com by rel...@osagesoftware.com on 5 Jan 2008 at 2:24

Attachments:

• gmpy_test..py
• gmpy_test.v1-02.out
• gmpy_test.v1-02-fix.out
• patch.64bit.txt

[GoogleCodeExporter]

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

Original comment by casevh on 22 May 2008 at 5:43

Attachments:

• patch.64bit_hash.txt

[GoogleCodeExporter]

Here's gmpy_test.py

Original comment by rel...@osagesoftware.com on 22 May 2008 at 11:41

Attachments:

• gmpy_test.py

[GoogleCodeExporter]

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"

Original comment by rel...@osagesoftware.com on 22 May 2008 at 10:26

Attachments:

• test_gmpy_0522.txt

[GoogleCodeExporter]

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

Original comment by casevh on 23 May 2008 at 4:28

• Changed state: Started

[GoogleCodeExporter]

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
>>> 

Original comment by rel...@osagesoftware.com on 23 May 2008 at 11:48

[GoogleCodeExporter]

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

Original comment by casevh on 23 May 2008 at 1:05

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for the fix!

Original comment by rel...@osagesoftware.com on 24 May 2008 at 3:54