mpz_limbs interface

[Zimmermann Paul]

       Niels,

sorry for the late reply, we were quite busy with the MPFR/MPC workshop
(which was very successful).

> > it seems it won't be sufficient for
> > our needs in MPFR. Consider for example the following function, which
> > generates nbits random bits into mp[]:
> 
> I see. In this particular case, I think the right gmp interface change
> is to add mpn_urandomb and mpn_rrandomb (similar to current mpn_random
> and mpn_random2, but with a randstate argument). If I understand this
> correctly, the main obstacle is that random number internals use mpz
> functions, which is an undesirable dependency for mpn functions.
> 
> Any other problematic cases?

I don't see other cases right now.

> >   MPFR_ASSERTN (nbits >= 1);
> >   /* To be sure to avoid the potential allocation of mpz_urandomb */
> >   ALLOC(z) = SIZ(z) = MPFR_PREC2LIMBS (nbits);
> >   PTR(z)   = mp;
> [...]
> >   mpz_urandomb (z, rstate, nbits);
> 
> I think this is brittle, and I don't think this style should be
> officially supported in the public gmp interface. mpz_urandomb is not
> included in mini-gmp, but if you, e.g., try the same with other
> functions, it will most likely break with mini-gmp which assigns many of
> the output parameters using mpz_swap.

of course if some random functions are provided at the mpn level, we will
use them and won't need to use that trick any more.

Paul