Ciao, 20 mag 2024, 16:40 da ni...@lysator.liu.se:
> Albin Ahlbäck <albin.ahlb...@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 _______________________________________________ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs