Fwd: gmpy moving to code.google.com

[Daniel Nogradi]

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