I have obsoleted these old functions and have provided some
replacements , however there are some potential problems. The old
mpn_random (and the other two) can not be "faked up" like we could
with mpz_probab_prime_p . ie we could do this
int mpz_probab_prime_p(mpz_t x,int reps)
{gmp_randstate_t rnd;int r;
gmp_randinit_default(rnd);
r=mpz_probable_prime_p(x,rnd,2*reps);
gmp_randclear(rnd);
return r;}and this would be no worse than the existing old code. However to do this for mpn_random is clearly useless (we get the same random number on each call) , so we have to retain the global variable for these functions.We could put some sort of locking mechanism on it , or do thread local storage , but perhaps for a mutil-threaded build we should just disable these old functions. Jason On Sep 13, 12:31 am, Bill Hart <[email protected]> wrote: > I agree, these are long overdue. Though again we'll have to obsolete > them and support them for years. > > Bill. > > 2009/9/12 Jason Moxham <[email protected]>: > > > > > Hi > > > These existing functions > > > Function: void mpf_random2 (mpf_t ROP, mp_size_t MAX_SIZE, mp_exp_t > > EXP) > > Generate a random float of at most MAX_SIZE limbs, with long > > strings of zeros and ones in the binary representation. The > > exponent of the number is in the interval -EXP to EXP (in limbs). > > This function is useful for testing functions and algorithms, > > since these kind of random numbers have proven to be more likely > > to trigger corner-case bugs. Negative random numbers are > > generated when MAX_SIZE is negative. > > > -- Function: void mpn_random (mp_limb_t *R1P, mp_size_t R1N) > > -- Function: void mpn_random2 (mp_limb_t *R1P, mp_size_t R1N) > > Generate a random number of length R1N and store it at R1P. The > > most significant limb is always non-zero. `mpn_random' generates > > uniformly distributed limb data, `mpn_random2' generates long > > strings of zeros and ones in the binary representation. > > > `mpn_random2' is intended for testing the correctness of the `mpn' > > routines. > > > do not accept a random state variable , hence I think they should be > > declared > > obsolete. They use a global state ( which of course will break with > > multi-threading) , we should of replace them with new functions which do > > accept a gmp_randstate. > > > We allready have this mpf function > > -- Function: void mpf_urandomb (mpf_t ROP, gmp_randstate_t STATE, > > unsigned long int NBITS) > > Generate a uniformly distributed random float in ROP, such that 0 > > <= ROP < 1, with NBITS significant bits in the mantissa. > > > The variable STATE must be initialized by calling one of the > > `gmp_randinit' functions (*note Random State Initialization::) > > before invoking this function. > > > so to "match" what we have for the mpz functions I think we should have a > > new > > function > > void mpf_rrandomb (mpf_t ROP, gmp_randstate_t STATE, unsigned long NBITS, > > mp_exp_t EXP) > > I not sure whether we need the EXP parameter or not ? any thoughts? , > > > And for the mpn random functions (again mirroring the mpz fn's) I think > > mpn_urandomm(mp_ptr rp, gmp_randstate_t STATE, mp_srcptr sp, mp_size_t n) > > mpn_urandomb(mp_ptr rp, gmp_randstate_t STATE, mp_size_t rpn) > > mpn_rrandomb(mp_ptr rp, gmp_randstate_t STATE, mp_size_t rpn) > > > Any thoughts? > > > Jason --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
