Reduced number of allocated limbs after calling mpz_remove

[marco.bodrato at tutanota.com]

Ciao,

20 mag 2024, 16:40 da nisse at lysator.liu.se:

> Albin Ahlbäck <albin.ahlback at gmail.com> writes:
>
>> In the project I help maintaining, we have started to rely on that mpz
>> never reduce the number of limbs. This is to keep a minimum number of
>> limbs allocated to 2
>>

With lazy allocation, we moved toward the opposite direction, but having at least two limbs when at least one is allocated anyway might be a good idea.


> Could you use mpz_limbs_write (x, 2) for the functions that want a
> result area of at least two limbs?
>

They can, but surely they want an already allocated couple of limbs for speed reasons, calling _limbs_write every now and then might not be in the spirit of the optimization.


>> Since this indeed seems to be the exception, I am fine with either
>> documenting that this indeed is the exception (perhaps it should then
>> be stated under the section "Memory management" as well as the
>> docstring for `mpz_remove`), or fixing this in `mpz_remove`.
>>

Actually the manual (https://gmplib.org/manual/Memory-Management ) reads:
"mpz_t and mpq_t variables never reduce their allocated space."

The mis-behaviour of mpz_remove is my fault. When I experimented with that function I tested both the "never reduce" and the "may reduce" version, but when I did commit I forgot to push the correct one.

https://gmplib.org/repo/gmp/rev/596470e0bc62

As you can see, the correct code is already there, but #if-ed out because WANT_ORIGINAL_DEST is not defined.

> I don't have a strong opinion on how to fix this discrepancy between
> docs and implementation.
>

I'll correct the _remove function, it's quite easy to do :-)


> But I feel rather strongly that mini-gmp
> shouldn't make this promise, so code that rely on it will not work with
> mini-gmp.
>

I agree for the mini-gmp side.

Ĝis,
mb