Extending the mpn interface

[bodrato at mail.dm.unipi.it]

Ciao,

Il Dom, 17 Febbraio 2013 10:22 pm, Niels Möller ha scritto:
> bodrato at mail.dm.unipi.it writes:

>>> /* Using an mpn number as an mpz. Can be used for read-only access

>>> mpz_srcptr
>>> mpz_init_mpn (mpz_ptr x, const mp_limb_t *xp, mp_size_t xs);

>> We may also allow write access, why not? I know it is dangerous...

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

We should at first decide if it make sense for the real GMP. Adding the
interface (the same, or with some limitations) to mini-gmp is only a
second step, in my opinion.

> But read-only access seems both safe and useful.

Of course!

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

Or mpn_set_z ...

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

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); }

Regards,
m

-- 
http://bodrato.it/papers/