[QUOTE=danaj;434206]Yes, that should be the most efficient method.
[list=1][*] Sieve a range using whatever appropriate tool to get just the candidates without small factors.
[*] Run PFGW on those candidates. This just runs its Fermat test with the default base. When one passes, congrats, you have your PRP.
[*] (Optional) A Fermat test is one of the weaker tests, so we might want to do a little better. [list][*] We could run PFGW with a few different bases. I believe this is what factordb does.[*] We could run Paul's program that does his Frobenius-Underwood test, which is an efficient and pretty stringent test. If you go through the math, it essentially runs a Fermat and Lucas test at the same time with a good base selection process. I believe this is better than running a few more Fermat bases. Since this uses gwnum it's quite fast for large numbers.[*] We could run BPSW. Sadly there is no gwnum implementation, so it will be much slower at the sizes we're talking about. Since we only run one, the speed isn't as critical. You could run various Frobenius tests as well, but I think a Fermat plus BPSW would be convincing enough: people who accept PRPs would think this is enough, while people that want proofs aren't going to be more convinced by further PRP testing.[/list][/list][/QUOTE]

Exactly! I would use the weak prp tests, then on one weak-prp result, preform more strong tests to see that it is even very unlikely to be composite, and in that case just treat them as primes after all tests are performed.

FWIW

Our wrapper script:

[c]until [ -e pfgw.log ]; do nice -19 ./program4.py > tmp && ../pfgw64 -f -k tmp; done; rm tmp && rm pfgw.ini[/c]

[c]program4.py[/c] is our (very lame) sieve program

More craziness here: [URL]http://www.mersenneforum.org/showthread.php?t=21252[/URL]

So far 50,000 digit PRPs have been (fairly easily?) found using our very slow NUC. We are slowly improving our sieve program before going larger.

YMMV

:mike:

[QUOTE=Xyzzy;434212]FWIW

Our wrapper program:

[c]until [ -e pfgw.log ]; do nice -19 ./program4.py > tmp && ../pfgw64 -f -k tmp; done; rm tmp && rm pfgw.ini[/c]

[c]program4.py[/c] is our (very lame) sieve program

More craziness here: [URL]http://www.mersenneforum.org/showthread.php?t=21252[/URL]

So far 50,000 digit PRPs have been (fairly easily?) found using our very slow NUC. We are slowly improving our sieve program before going larger.

YMMV

:mike:[/QUOTE]

My record for prps stands at 6,056 digits and want it to be slightly more than 200k digits. (200,192 digits for computing at least.) Your wrapper program should definitely help as well! :bounce:

We forgot to mention this:

Our sieve program is most likely slower than just feeding pfgw the unsieved candidates, but we want to convince ourselves that we have done at least a little of the programming to find stuff. Perhaps it gives us the illusion of control?

We are interested in improving our code but most suggestions will be beyond our math understanding. We hope to slowly remedy this.

The following code is lame, but for us it represents a lot of hard work and learning:

[CODE]#!/usr/bin/python

from random import randint
from random import randrange

mp = 46
length = 50000
sievesize = 1000000

def quicktest(n):
for p in smallprimes:
if n % p == 0:
return False
return True

def sieve(n):
multiples = set()
for i in range(2, n + 1):
if i not in multiples:
yield i
multiples.update(range(i * i, n + 1, i))

smallprimes = list(sieve(sievesize))

with open(str(mp)) as f:
data = f.read()

flag = False

while flag == False:
start = randint(0, len(data) - length)
result = int(data[start:start + length])
if len(str(result)) == length:
if result % 10 == 1 or result % 10 == 3 or result % 10 == 7 or result % 10 == 9:
if quicktest(result) == True:
print result
flag = True[/CODE]

The sieve size I can choose, but I hope I do not pick a large range with no primes, that's the worst, though composites are limited by maximum prime gaps.

Here is a sieve example:

ABC2 233100857649...(200k+digits)...210016697705+$a

a: from 1 to 1000000 "step 2"

then auto-stop prp testing when one prime (prp) is found.

(As I am confused at "step 2" though I think I am just locating another .txt file with my remaining candidates.)

For generating a list of primes in python, [URL="http://stackoverflow.com/a/3035188/3126317"]RWH's python functions[/URL] are short and very fast.

One thing I don't see in the docs is how to make PFGW stop once it finds a PRP. Your (Xyzzy) script would seem to make pfgw run on every value. Maybe that's ok -- you just find multiple PRPs. It does avoid the overhead of making the script call it one at a time.

For something not too dissimilar to generate a random 50k digit number then sieve 100k to depth 1e8:
[code]
perl -Mntheory=:all -E 'use bigint; my $n = join("",1+int(rand(9)),map { int(rand(10)) } 2..50000); say for Math::Prime::Util::GMP::sieve_primes($n,100000+$n,1e8);' >foo
[/code]
or with my dev version with a bit less overhead:
[code]
perl -Mntheory=:all -E 'my $n = join("",1+int(rand(9)),map { int(rand(10)) } 2..50000); say "$n+$_" for sieve_range($n,100000,1e8);' >foo
[/code]

Sieving to 1e6 takes under a second, and is too little for best efficiency.
Sieving to 1e9 on the 50k-digit random input with width 100k takes about 90 seconds.
Sieving to 1e9 on 100k-digit random input with width 500k takes about 3 minutes.
We would want deeper sieving for these sizes, but this shows the idea and gives an indication of time.

It looks like your program generates many random results, while mine is generating one then sieving a range. This should be more efficient than the trial division on each candidate.

Looks like PFGW is taking about 90-100 seconds for each 50k-digit candidate (with no trial factoring).

For 100k-digits it is taking about 400 seconds. About 4x longer for 2x larger input, which is great vs. the ~6x longer time for GMP BPSW for doubling bits. That doesn't count the lowered expectations of finding a prime at the larger size, meaning more expected tests per PRP found.

[QUOTE=PawnProver44;434218]Here is a sieve example:

ABC2 233100857649...(200k+digits)...210016697705+$a

a: from 1 to 1000000 "step 2"[/QUOTE]

Hopefully, while doing this in real life, you'll manage to not generate only even numbers as you're doing in the example :smile:

[QUOTE=axn;434262]Hopefully, while doing this in real life, you'll manage to not generate only even numbers as you're doing in the example :smile:[/QUOTE]
:blush: hahaha :smile:
BTW, couldn't he use +2*$a and avoid the "step 2" contraption? beside of the fact he said he is confused by it, the increment would be faster :razz:
Told ye he is only trolling...

[QUOTE=danaj;434228]One thing I don't see in the docs is how to make PFGW stop once it finds a PRP. Your (Xyzzy) script would seem to make pfgw run on every value. Maybe that's ok -- you just find multiple PRPs. It does avoid the overhead of making the script call it one at a time.[/QUOTE]The [URL="http://www.mersenneforum.org/showpost.php?p=434212&postcount=57"]wrapper script[/URL] looks to see if a pfgw.log file exists, and quits if it does. The pfgw.log file is only written if a PRP is found.

:mike:

Sucess!! :banana:

nextprime(233100857649...(200k+digits)...210016697705) = 233100857649...(200k+digits)...210016702491

:banana: :banana: :banana:

My point: I actually had someone else give me an output example using everything suggested here to give me a sample output of a "random" prp that size.

[QUOTE=Xyzzy;434272]The [URL="http://www.mersenneforum.org/showpost.php?p=434212&postcount=57"]wrapper script[/URL] looks to see if a pfgw.log file exists, and quits if it does. The pfgw.log file is only written if a PRP is found.[/QUOTE]Ah, I thought the Python script was writing multiple lines to the file. It seems to try to open a file named 46, so I couldn't run it, but now I see it just writes one line at a time.