ni...@lysator.liu.se (Niels Möller) writes: 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. We should indeed do this.
The random number framework uses the following mpz functions: mpz_add_ui mpz_addmul_ui mpz_clear mpz_clrbit mpz_export mpz_fdiv_r_2exp mpz_init mpz_init2 mpz_init_set mpz_init_set_str mpz_mod mpz_mul mpz_setbit mpz_sub_ui mpz_tdiv_q_2exp mpz_tdiv_r_2exp mpz_tstbit This should be fairly easy to rewrite to use mpn. For testing the result, I'd write a wrapper C program that run old and new code in separate processes, and compare that the results are identical for the same (now and then regenerated) seeds. There is a pseudo-dependency on mpz in the gmp_randstate_t type, since the _mp_seed if of type mpz_t. To clean that up without causing binary incompatibility, we could just define a type with the exact same components as mpz_t. Torbjörn Please encrypt, key id 0xC8601622 _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel