Torbjorn Granlund t...@gmplib.org writes:
ni...@lysator.liu.se (Niels Möller) writes:
One can have alternative functions accepting mp_limb_t and
mp_limb_signed_t, if one finds that useful.
That would be nice, and so would functions accepting long long.
But unfortunatly, neither is
Marc Glisse marc.gli...@inria.fr writes:
Imagine that mpz_set_si takes as argument a long long on win64. I can
still pass it a long with no problem. Imagine that mpz_get_si outputs
a long long. I can still store it safely in a long, because I first
called mpz_fits_slong_p to check that it
On Wed, 7 Mar 2012, Niels Möller wrote:
Marc Glisse marc.gli...@inria.fr writes:
Imagine that mpz_set_si takes as argument a long long on win64. I can
still pass it a long with no problem. Imagine that mpz_get_si outputs
a long long. I can still store it safely in a long, because I first
bodr...@mail.dm.unipi.it writes:
The first one is the one I prefer. Has this problem been addressed in the
alimb branch?
We generalised this and separated long and size arithmetic from limb
arithmetic.
More work is needed on the alimb code, and help is most welcome. I
think Per Olofsson
ni...@lysator.liu.se (Niels Möller) writes:
One can have alternative functions accepting mp_limb_t and
mp_limb_signed_t, if one finds that useful.
That would be nice, and so would functions accepting long long.
But unfortunatly, neither is possible if we want one GMP interface per
release,
On Tue, 6 Mar 2012, Niels Möller wrote:
Marc Glisse marc.gli...@inria.fr writes:
Note that mpir is replacing signed/unsigned long by two typedefs that
can be defined as (unsigned) long long on _LONG_LONG_LIMB platforms.
That works around the problem too...
(actually they don't seem to have
