Extending the mpn interface
bodrato at mail.dm.unipi.it
bodrato at mail.dm.unipi.it
Sat Feb 16 11:08:37 CET 2013
Ciao,
Il Ven, 15 Febbraio 2013 3:51 pm, Niels Möller ha scritto:
> /* Return limb pointer, for read-only operations. Use mpz_size to get
> the number of limbs. */
> const mp_limb_t *
> mpz_read_limbs (const mpz_srcptr x);
mpz_srcptr already is const, isn't it?
> /* Get a limb pointer for writing, previous contents is intact.
> Grows allocation if needed to make room for n limbs. */
> mp_limb_t *
> mpz_modify_limbs (mpz_ptr x, mp_size_t n);
You mean that allocation doesn't shrink, right? So n=0 can be used if one
knows in advance that the mpn operations can not give a larger number. We
may say that n=0 is equivalent to n=mpz_size (x).
> /* Using an mpn number as an mpz. Can be used for read-only access
> only. x must not be cleared or reallocated. Here and below, xs
> stands for a signed parameter, where abs(xs) is the size, and xs <
> 0 indicates a negative number. Returns x, cast to const, so it can
> be used directly as an argument for other mpz functions. */
> mpz_srcptr
> mpz_init_mpn (mpz_ptr x, const mp_limb_t *xp, mp_size_t xs);
Maybe _roinit is a better name, if it is read-only.
We may also allow write access, why not? I know it is dangerous, but it is
not more dangerous than an mpz initialized with the already documented
mpz_array_init function...
> /* Copy x, which must be at most xn limbs, to the {xp, xn} area,
> zero-padding if needed. Not sure what to do if x is too large to
> fit, or if x < 0. */
> void
> mpz_get_mpn (mp_limb_t *xp, mp_size_t xn, const mpz_t x);
If the general idea is: zero-pad if read-only; then zero-padding here is
not needed.
> /* Assigns x from the area {xp, abs(xs)}. */
> void
> mpz_set_mpn (mpz_t x, const mp_limb_t *xp, mp_size_t xs);
We have mpz_set_q, mpz_set_f, mpq_set_z... should we call this one mpz_set_n?
Regards,
m
--
http://bodrato.it/software/strassen.html
More information about the gmp-devel
mailing list