> > Could you please tell me, on that 64-bit build, what happens with: > > > >>> importgmpy, sys, operator > > >>> sys.maxint > > ??? > > >>>gmpy.mpz(sys.maxint) > > ??? > > >>> operator.index(gmpy.mpz(sys.maxint)) > > ??? > > >>> sys.maxint+1 > > ??? > > >>>gmpy.mpz(sys.maxint+1) > > ??? > > >>> operator.index(gmpy.mpz(sys.maxint)+1) > > ??? > > > i.e., what are the values correspondiing to the ??? occurrences when > > you actually do that...? > > Here it goes (python 2.5 - 64bit): > > >>> importgmpy, sys, operator > >>> sys.maxint > 9223372036854775807 > >>>gmpy.mpz(sys.maxint) > mpz(-1) > >>> operator.index(gmpy.mpz(sys.maxint)) > -1 > >>> sys.maxint+1 > > 9223372036854775808L>>>gmpy.mpz(sys.maxint+1) > > mpz(9223372036854775808L)>>> operator.index(gmpy.mpz(sys.maxint)+1) > > 0 > > I don't pretent to fully understand what's going on, > butgmpy.mpz(sys.maxint)==gmpy.mpz(-1) is more than suspicious :)
[directing Alex's message back to the list] Yes, clearly there is some 32-vs-64 bit assumption around. When I create an mpz from a Python int (a PyObject* i which passes Python's int typecheck) I do that by calling mpz_from_c_long(PyInt_AsLong(i)) -- depending on what "long" means in C, I guess that might be the root of the problem. There might be similar problems in creating mpq and mpf from Python ints > 2**31-1 on 64-bit platforms, I guess. I could try flailing around in the dark to fix it, but, without access to a 64-bit Python platform, I don't really see any chance of me fixing this. If somebody can give me ssh access to such a platform, I'll be glad to work to give it a try; of course, if anybody who does have access to such a platform wants to send me patches or join the gmpy project, that would also be great; failing either of these options, I don't see much that I could do beyond pointing out in the docs that gmpy does not correctly support 64-bits builds of Python, checking for them in the unittests, etc. Thanks, Alex -- http://mail.python.org/mailman/listinfo/python-list
