Extending the mpn interface

Niels Möller nisse at lysator.liu.se
Mon Feb 18 10:10:03 CET 2013

bodrato at mail.dm.unipi.it writes:

> We should at first decide if it make sense for the real GMP.

My gut feeling is no. If you want to compute a result into an mpn
variable, and the "best" way to do that is by calling some mpz function,
then that would typically mean that an mpn-level function is missing.

Do you have any example use cases, inside or outside of GMP itself?

> I prefer to have this functions in the mpn interface. Implying: "is the
> responsibility of the caller to ensure that the destination has enough
> space", and "no time is spent on things that not all callers need".
> mp_size_t mpn_set_z (mp_ptr xp, mpz_srcptr x)
> { MPN_COPY (xp, PTR (x), ABSIZ (x)); return SIZ (x); }

I see your point. I think I'll leave these convenience functions out for
now (and I think I'd prefer the name mpz_get_n). Your variant could also
easily be done as

#define mpz_get_n(xp, x) \
  (mpn_copyi (xp, mpz_read_limbs (x), mpz_size(x)))

on top of the "essential" mpn/mpz functions. And my variant could be
done with an additional mpn_zero. So we could leave it for the
application to define whatever copying functions are most convenient.


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