Lazy mpz allocation

Niels Möller nisse at lysator.liu.se
Wed May 4 13:03:38 UTC 2016


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).

/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.


More information about the gmp-devel mailing list