Extending the mpn interface

[bodrato at mail.dm.unipi.it]

Ciao Niels,

Il Lun, 4 Febbraio 2013 11:40 am, Niels ha scritto:
> I really think something similar should be added to GMP.

I agree.

This interface is "dangerous" for beginners, that's why I like the _mpz
prefix. But it is powerful for experienced users, that are probably using
internals anyway... We should give a stable interface to switch mpz<->mpn.


In a previous message of yours, you also suggested that mpz_size should be
in the same "namespace". I agree, we should rename it to _mpz_size (but
this is an incompatible change :-)


But I do not agree on some details of your proposal:

1) Zero-padding. _mpz_read_limbs_n overwrite the unused area with zeros,
_mpz_modify_limbs does not. Why? I think they should be the same function:
inline const mp_limb_t * _mpz_read_limbs_n (mpz_ptr x, mp_size_t n)
 { return _mpz_modify_limbs (x, n); }

2) _mpz_done_limbs should take care of the sign.

3) _mpz_init_mpn (maybe mpz_roinit_n is a better name) sets _alloc=0. I
remember you suggested this as a mark for read-only mpzs, but it is
currently unsupported by the library (with --enable-assert). I'd suggest
 x->_mp_alloc = ABS (xs);

4) I'm not sure I understand the need for _mpz_copy_limbs, it can be
obtained with mpz_export (padding excepted). We may decide to add some
easier way to import/export to mpn, I'd suggest the interface:
void mpz_set_n (mpz_t, mp_srcptr, mp_size)
mp_ptr mpz_set_n (mp_ptr, &mp_size, mpz_srcptr)

5) I'm not sure I understand the need for _mpz_cmp_limbs.

Best regards,
m

-- 
http://bodrato.it/