Extending the mpn interface

[Niels Möller]

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.

Regards,
/Niels

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