Extending the mpn interface

[bodrato at mail.dm.unipi.it]

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