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