Why is _mp_size not of type mp_size_t?
tege at swox.com
Thu Nov 3 12:55:53 CET 2005
Roberto Bagnara <bagnara at cs.unipr.it> writes:
Notice that I am not posting this to gmp-bugs because it is not, I believe,
a bug of GMP: we are fiddling with the internal details of GMP and this is
something that goes beyond the API. Nonetheless, I wonder why many GMP
functions accepts parameters of type `long int' (on non-Crays) when they
can never handle anything that does not fit `int'.
I'm afraid I don't follow your reasoning here.
(I don't think any mpz/mpq/mpf functions accept mp_size_t arguments.
The _ui functions accept an (unsigned) long int but that's 32-bit or
64-bit numerical data, which will at most add 32 or 64 to the
Is this apparent discrepancy intended? (I know that a size of 2^31-1 fits
all present and future purposes, but this does not explain why mp_size_t
can go beyond that limit.)
Yes, this is intended. It saves a lot of memory for smallish numbers
on 64-bit systems, since the mpz_t will use 24 bytes instead of 32
We use mp_size_t in the mpn layer to allow larger precisions there,
and mp_size_t in scalars elsewhere since 64-bit scalar arithmetic is
often somewhat faster on 64-bit machines. (Now there is an exception
to this rule in the AMD64 clone Pentiums, where 64-bit arithmetic is
often much slower than 32-bit arithmetic.)
More information about the gmp-discuss