Maximum number of bits in an mpz_t
bagnara at cs.unipr.it
Sat Apr 24 22:59:39 CEST 2004
Torbjorn Granlund wrote:
> Roberto Bagnara <bagnara at cs.unipr.it> writes:
> is there a portable way for an application using GMP's
> mpz_t (seen as a collection of bits) to know the maximum
> number of bits a mpz_t can handle?
> I am afraid I don't understand your question.
> An mpz_t allocates more memory as the value "needs more bits",
> which makes the available swap space and setrlimit-style
> resource caps the the only limits.
I would like to know what the theoretical limit is,
in an architecture independent way (no matter how funny
an architecture may be), and not looking at the contingent
implementation of the library.
If I look at the current implementation, the declaration
int _mp_alloc; /* Number of *limbs* allocated and pointed
to by the _mp_d field. */
int _mp_size; /* abs(_mp_size) is the number of limbs the
last field points to. If _mp_size is
negative this is a negative number. */
mp_limb_t *_mp_d; /* Pointer to the limbs. */
seems to suggest that GMP_LIMB_BITS*INT_MAX is a hard limit for the number
of bits. However: (1) I cheated because I have looked at the implementation;
(2) I don't know if there are other limitations to the maximum number
of bits (I know nothing about nails, the algorithms employed and so forth).
What I am looking for is something similar to the max_size() method of the
STL container, something that spares the user from the need to guess.
P.S. With the current version of mpz_setbit() and other bit operations,
"only" ULONG_MAX bits are accessible, but this is another story.
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
mailto:bagnara at cs.unipr.it
More information about the gmp-discuss