Extending the mpn interface

[Niels Möller]

bodrato at mail.dm.unipi.it writes:

> 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?

Right.

>> /* 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?

Yes. If for some reason one wants to shrink the allocation, one could
use _mpz_realloc instead. I suspect that's an uncommon use.

> We may say that n=0 is equivalent to n=mpz_size (x).

I guess so.

>> /* 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.

Maybe. At least that would make it clearer that it's different from the
other init function.

> 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...

I'm considering adding the same interface also to mini-gmp, once we have
settled on how it should look like. And there it's even more dangerous,
since lots of functions assign the output variable using mpz_swap. (And
it also makes _mpz_realloc mostly useless).

But read-only access seems both safe and useful.

>> /* 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.

I'm not following you. The idea is that the output area is of fixed
size, and that all those limbs should get correct values, even if the
mpz input happens to be small. I see that there are other reasonable
conventions too.

>> /* 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?

Makes some sense. And also mpz_get_n, for consistency? (But I think I'll
wait with these non-essential functions, and get the more essential ones
done first).

Regards,
/Niels

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