Reduced number of allocated limbs after calling mpz_remove

Niels Möller nisse at lysator.liu.se
Mon May 20 09:06:35 CEST 2024


Albin Ahlbäck <albin.ahlback at gmail.com> writes:

> It is stated in the documentation that "mpz_t and mpq_t variables
> never reduce their allocated space.", which is sort of true given that
> `x` and `dest` are only being swapped, but that requires the user to
> know what the internals are doing.

Whenever an mpz function is called with destination operant equal to one
of the inputs, and the lower-level functions don't support in-place
operation, mpz functions would need to either

1. allocate new storage for the result (violating the above property),
or

2. allocate a copy of the inputs.

It looks like mpz_remove does option (1), while, e.g., mpz_tdiv_qr
follows option (2). I would prefer to give the implementation a bit more
freedom. And mini-gmp follows (1) rather aggressively, even when there
is no argument overlap.

So not sure if code or docs should be adjusted ("usually not" rather
than "never"). Do you think the "never reduce their allocated space"
property is important for your usecase, or for other GMP applications
general? If the strong statement is kept, this should perhaps be mention
as another execption in mini-gmp/README.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.


More information about the gmp-bugs mailing list