I also prefer the name mpz_likely_prime. No one is going to wonder what that means, it is self explanatory. Jason, I'm not sure we are understanding what you mean precisely by not liking the whole mpz_next_prime thing. I use it all the time and I'm pretty sure it is a really commonly used thing. Actually it returns very few composites, so it is very useful in many situations.
But I'm not 100% sure you meant get rid of any next_prime facility altogether. That would break an awful lot of code out there. Did you mean you didn't like calling it next_prime or you didn't like how it was currently being done? Or did you just mean you wanted to get rid of any such facility. I think the latter would be a very bad step. I agree it doesn't fit very well. I think the sieve idea would be more consistent with the rest of the library. But even still, many times when prototyping something you really want an mpz_nextprime_quick_dirty_no_fuss_not_too_much_typing() Bill. 2009/9/4 Jason Moxham <[email protected]> > > On Friday 04 September 2009 11:03:23 Jeff Gilchrist wrote: > > On Thu, Sep 3, 2009 at 10:51 PM, Jason Moxham<[email protected]> > wrote: > > > Or getting rid of the mpz_next_prime_thing all-together , cant say I > like > > > it much. What do people use it for ? > > > > To me , it just doesn't "fit" with the rest of the library , I can't > explain > it more than that :) > > > I actually use it and find it very useful. If I'm doing some kind of > > testing or other calculations on increasing primes it is very useful > > just to call that function to get the next one to work with. > > > > Anyway regardless of my clearly reasoned argument above :) :) , if you find > it > usefull , then thats a good enough reason to keep it/improve it. > Ideally we have some sort of state that we can pass to the nextprime > function , I suppose we could add it to MPIR now (pointer to a structure), > and we could fill in the details later. > > > Right now unless you dig into the code it is hard to tell what the two > > current prime functions really do. > > It should be clear in the docs what they do , just not how they do it. > > > So a new defined function that > > either provides a way to specify the algorithm to use or have > > something very clearly defined would be a great benefit. > > We can add specific algorithms later , it is something I plan to do , if > everyone else thinks its a good idea. > Perhaps we should set up a new directory for future extentions , where we > can > thrash out the details of algorithms and interfaces. Until you actually > write > and use the code in a few situations you can never be sure what is the > "best" > way to do it. If we have code as well then users can give us feedback on > what > really get used. > > > If someone > > is trying to do work that needs to be repeatable it would be good to > > have a way for people to say, "Use MPIR with this is_prime/prob_prime > > function using these parameters" > > > > The new functions are all deterministic given the same random state. > > > Jeff. > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
