Lazy mpz allocation

[Marc Glisse]

On Wed, 4 May 2016, Niels Möller wrote:

> Marc Glisse <marc.glisse at inria.fr> writes:
>
>> The fact that an mpq is made of 2 mpz that can be accessed directly is
>> part of the interface. I think following your suggestion would mean
>> changing that.
>
> I guess you're right, it would break mpq_denref. Which I guess is also
> expected to work on a const mpq_t, so it's not an easy solution to
> redefine it to do lazy assignment.
>
> And it's used in quite a lot of places, debian codesearch lists the
> following packages:
>
>  python-gmpy, llvm-toolchain-3.8, mpfr4, lcalc, yap, flint-arb, mlgmp,
>  ats-lang-anairiats, givaro, parrot, llvm-toolchain-snapshot, librep,
>  linbox, python-gmpy2, swi-prolog, libgmpada, isl, polymake, kcalc,
>  pynac, flint, pike7.8, apron, cloog, llvm-toolchain-3.7, pike8.0,
>  ocamlcreal, qsopt-ex, gambas3, cgal, surf-alggeo, singular, cvc3, gmp,
>  regina-normal, gcl, ppl, libaqbanking, gmp-ecm, zimpl, ats2-lang,
>  ledger, libalkimia, gfan, guile-1.8, genius, postgresql-pgmp
>
> But I'm not giving up just yet. Would it be possible to initialize the
> denominator as
>
>  static const mp_limb_t the_one = 1;
>
>  q->_mp_den._mp_alloc = 0;
>  q->_mp_den._mp_size = 1;
>  q->_mp_den._mp_d = (mp_limb_t*) &the_one;
>
> (This kind-of requires that _mp_alloc == 0, _mp_size != 0 is supported
> in general for mpz_t, meaning any modification requires new storage, and
> that the storage pointed to by _mp_d should not be deallocated by gmp).

That looks pretty much like the copy-on-write thing you and Marco were 
discussing last year

https://gmplib.org/list-archives/gmp-devel/2015-September/004169.html

It should be possible, but it may require changing quite a number of 
places in the code.

-- 
Marc Glisse