Feeding the factors to Sage's factor command to check they are prime is precisely what proof=true is all about. Testing primality in a proven way, for numbers bigger than 10^16 is still very slow as there is no really good algorithm known for it. I have some code written by a student of mine (Peter Shrimpton) in C to push this bound much higher. But it needs some serious optimisation and to be run on a large cluster. If anyone is interested, I can make it available, as it is GPL'd.
In the case I reported, there is no issue with proof=true, as the numbers involved were well below Pari's cutoff. It's simply a red herring to be thinking about proving primality of the factors. I believe it is well understood why the Sage factor command is so much slower. Bill. On 9 Apr, 22:14, mabshoff <mabsh...@googlemail.com> wrote: > On Apr 9, 2:11 pm, mabshoff <mabsh...@googlemail.com> wrote: > > > On Apr 9, 2:03 pm, Peter Jeremy <peterjer...@optushome.com.au> wrote: > > <SNIP> > > > The primality test for pari is known to be lead to false results up to > > 10^14 or so (FLINT's is up to 10^16 IIRC what Bill told me a couple > > days ago). > > Opps, I don't know what I was thinking, but the above makes no sense > as written: What I wanted to write was that pari's probabilistic > primality test is known to be correct for up to some bound around > 10^14. Sorry for the double post. > > Cheers, > > Michael --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
