Hi The new mpz_probable_prime_p and the old mpz_probab_prime_p functions use a probabilistic algorithm for deciding on the primeallity(Oh ,my spell-check doesn't seem to have that word in it's dictionary!!) of a given number and these algorithms require a source of random numbers. The old probab_prime function uses an internal source which therefore is either global(and therefore not thread safe) or initialised on each call and therefore not random (so invalidating the algorithm). To obtain a truly random and threadsafe function we require that a random_state be passed to the function.
As for MPIR/GMP compatibility , we do strive to be a drop in replacement for GMP , however some changes that should be made to improve the performance or usability can cause problems , but hopefully working with the users we can try to achieve both with only minimal hassle :) Jason On Thursday 18 March 2010 21:08:58 Chris Saunders wrote: > Thanks for the reply Brian and Bill Hart also. I have changed my mind and > decided to claim MPIR compatibility instead of GMP compatibility for my > Eiffel interface. Now I have a question about another function - > mpz_probable_prime_p. It seems odd to me that this functions has a > gmp_randstate_t argument. Could I ask what the purpose of this argument > is? > > Regards > Chris Saunders > > -------------------------------------------------- > From: "Cactus" <[email protected]> > Sent: Thursday, March 18, 2010 8:00 AM > To: "mpir-devel" <[email protected]> > Subject: [mpir-devel] Re: Question on mpz_probab_prime_p > > > On Mar 18, 11:21 am, "Chris Saunders" <[email protected]> wrote: > >> I was reading the documentation on mpz_probab_prime_p. At the bottom of > >> the > >> documentation of this function it says "This function is obsolete. It > >> will > >> disappear from future MPIR releases." I have not seen the same in the > >> GMP > >> documentation for this function. Does this mean that in the future I > >> can expect GMP and MPIR to be incompatable? Might I suggest that this > >> would be > >> unfortunate. > > > > Although our general intention is to remain as compatible as possible, > > GMP and MPIR will never be completely exchangeable as their are always > > going to be a few functions that will exist in one but not in the > > other. > > > > For example, we will never implement the so called 'secure' functions > > such as mpn_powm_sec() since we don't consider it sensible to use > > either GMP or MPIR where security matters as the code is completely > > inappropriate for such uses. > > > > In the area of trial division and (probable) prime testing, there is > > currently some divergence that needs careful consideration. We have > > not planned a way ahead on this right now but we do see the > > maintenance of a high level of GMP/MPIR compatibility as important > > where the path taken by GMP makes sense. > > > > Brian > > > > -- > > 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. -- 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.
