![]() |
|
|
#12 |
|
"Dana Jacobsen"
Feb 2011
Bangkok, TH
90810 Posts |
PFGW's nextprime is not at all optimal (with 3.7.10 at least). It does a shallow small factor check followed by WraithX's GMP BPSW test. It's significantly slower than Pari or Perl/ntheory, when for large inputs (4000+ digits) it could be much faster if it did a sieve followed by its PRP tests, with the BPSW test reserved for anything passing the PRP test.
Of course for the trivial sizes you're showing (sub-40 digits) you're measuring completely wrong. next_prime for 40 digit inputs should be taking less than a millisecond. For next prime of 10^2000: 22s Perl/ntheory 128s Pari/GP 2.8.0 (55e7256a) 231s PFGW 3.7.10.64bit Once you get into the 2k-10k range and larger, the fastest strategy I know is to use a sieve (Perl/ntheory or newpgen or whatever) followed by PFGW on each candidate (so it runs the fast PRP test), followed by a better test on the result (Pari/GP, Perl/ntheory, etc.). There isn't any really convenient one-stop solution right now. There's another thread that was discussing this, and if I had a good gwnum standalone base-2 M-R test I could easily add it to my code. A standalone Fermat would work also -- the one in PFGW exists but doesn't look easy to take out. Last fiddled with by danaj on 2016-05-12 at 22:01 Reason: best -> fastest |
|
|
|
|
|
#13 |
|
"NOT A TROLL"
Mar 2016
California
110001012 Posts |
I do not think any of those programs can handle nextprime(x) for x around 200k digits, and I think no text editor would support at least 500k lines of next, but if any please let me know of a few editors I can use for something like this:
nextprime(input.txt); (random 200k digit number) Result = inputprime.out (decimal expansion of nextprime(x)) |
|
|
|
|
|
#14 |
|
"Dana Jacobsen"
Feb 2011
Bangkok, TH
22·227 Posts |
It depends what you mean by "cannot handle." All three tools ought to work. I've used mine for 100k inputs before, but the time taken can be extreme. I don't see why Pari/GP would have any issues with large inputs other than the time taken.
vim and emacs will both handle 500k character lines without a problem. Older versions of vi work but get slow for such long lines. You can also just generate 500k random digits with a program and have it output to your file. You could also just do something like: Code:
perl -Mntheory=:all -E 'prime_set_config(use_primeinc=>1); say random_ndigit_prime(1000);' I would think that doing next_prime of simple expressions would be more palatable than completely random PRPs. It sounds like there are already issues with submitting giant numbers like these. Wouldn't next_prime(10^100000+10^12345) or something be different enough and yet still easily describable? |
|
|
|
|
|
#15 | |
|
"Rashid Naimi"
Oct 2015
Remote to Here/There
80F16 Posts |
Quote:
Last fiddled with by a1call on 2016-05-12 at 23:21 |
|
|
|
|
|
|
#16 | |
|
"NOT A TROLL"
Mar 2016
California
197 Posts |
Quote:
The problem with prp testing each candidate is the command line will freeze due to several lines of digits. Ntheory should not take more than two weeks for this using the same processor is my guess? Thanks. Seems complicated to me. |
|
|
|
|
|
|
#17 |
|
"Dana Jacobsen"
Feb 2011
Bangkok, TH
22×227 Posts |
Pari/GP easily generates large random numbers. E.g.
Code:
echo 'random(10^1000)' | gp -f -q > /tmp/input.txt |
|
|
|
|
|
#18 |
|
Sep 2002
Database er0rr
1110101100102 Posts |
Something like the following might work:
Code:
c=0;for(k=1,10000,n=random(10^500000);forprime(p=2,1000000,if(n%p==0,break(2)));c=c+1;write("pf500000.txt",n));print(c" numbers added")
Last fiddled with by paulunderwood on 2016-05-15 at 19:05 |
|
|
|
|
|
#19 |
|
"NOT A TROLL"
Mar 2016
California
197 Posts |
Set nextprime(2^620000) in pfgw a month ago and it is still working on it
. For perl n/theory, I still get over a month (unless I am extremely lucky) using the same processor.I am currently unsure if Pari/GP or perl/ntheory do sieves before prp testing remaining candidates for next_prime(n). Last fiddled with by PawnProver44 on 2016-05-15 at 19:16 |
|
|
|
|
|
#20 |
|
Sep 2002
Database er0rr
2×32×11×19 Posts |
This is better code for random primes. (The previous code I gave only produce one candidate
)Code:
c=0;for(k=1,100,n=random(10^500000);factored=0;forprime(p=2,1000000,if(n%p==0,factored=1;break));if(factored==0,c=c+1;write("pf500000.txt",n)));print(c" numbers added")
5 numbers added
Last fiddled with by paulunderwood on 2016-05-15 at 19:24 |
|
|
|
|
|
#21 | |
|
"NOT A TROLL"
Mar 2016
California
197 Posts |
Quote:
|
|
|
|
|
|
|
#22 |
|
Sep 2002
Database er0rr
2·32·11·19 Posts |
I don't why that pari/gp should do that. Heat? Lack of memory? Watch out for the file size of "pf500000.txt"!
Last fiddled with by paulunderwood on 2016-05-15 at 19:32 |
|
|
|
![]() |
| Thread Tools | |
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Near- and quasi-repunit PRPs | Batalov | And now for something completely different | 10 | 2019-09-12 13:31 |
| OEIS - 2^n-5 - LLT-like algorithm for finding PRPs | T.Rex | Miscellaneous Math | 13 | 2015-09-01 13:09 |
| PRPs not prime | schickel | FactorDB | 1 | 2015-08-03 02:50 |
| Proven PRPs? | Random Poster | FactorDB | 0 | 2012-07-24 10:53 |
| PRPs that are composites | gd_barnes | Conjectures 'R Us | 57 | 2011-09-12 12:31 |