On Friday 04 September 2009 16:34:18 Bill Hart wrote: > 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.
Thats the only reason I can think of "doesn't fit" , I suppose in a perfect world , this would be in another library you would use with MPIR and it would provide a big bucket of prime stuff. As no such library exists and it would break existing code then we should leave it alone. > 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() Functions/macros for prototyping are certainly worth having , I use them all the time , I have just never used that particular one. > > 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 -~----------~----~----~----~------~----~------~--~---
