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 _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel