Riesel base 3 - mini-drive I

[rogue]

Originally Posted by mdettweiler

Well, PRPnet uses standard LLR and Phrot executables for its actual primality testing, so the tests should be sound, assuming of course that the machines running the tests are stable, as usual. And we'll know if the server setup is reporting primes correctly as soon as the server receives its first PRP.

Also, I will definitely be 100% sure at the end of the range that no k/n pairs have been skipped, since after processing the results into normal LLR format as I do with LLRnet results, I will be verifying them all with the original sieve file using the exact same proven-reliable method that I use for LLRnet results.

phrot and LLR do a PRP test, not a primality test. You must use PFGW to prove primality.

[mdettweiler]

PRPnet G3000 has completed 75K-76K; results are attached. One prime found by nuggetprime on the server, and proven with PFGW by me:

39638582*3^75684-1 is prime! (322.4671s+0.0037s)

[VBCurtis]

It appears this drive has eliminated 60% of the k's in the file during tripling of the n-bound (25k to 75k). Does the math work in such a way that you expect another tripling of n-bound to eliminate another 60% of the candidates? i.e. 75k to 225k.

After a post in the sieve-depth thread, I thought I'd try to work out some estimate for expected primes and their effects on optimal sieve depth.
-Curtis

[henryzz]

Originally Posted by VBCurtis

It appears this drive has eliminated 60% of the k's in the file during tripling of the n-bound (25k to 75k). Does the math work in such a way that you expect another tripling of n-bound to eliminate another 60% of the candidates? i.e. 75k to 225k.

After a post in the sieve-depth thread, I thought I'd try to work out some estimate for expected primes and their effects on optimal sieve depth.
-Curtis

from what i have read it will be slightly less for the next tripling because the average weight of the ks will probably be lower

[gd_barnes]

Originally Posted by henryzz

from what i have read it will be slightly less for the next tripling because the average weight of the ks will probably be lower

This is absolutely correct. Frequently you'll wind up with just a few k's remaining that are so much lower average weight than the k's up to that point that it will take them far longer than other k's to find a prime.

But...Curtis, to make the math a little easier, you could go ahead and assume just what you said since there are so many k's remaining. You only see the large reduction in the amount of reduction (lol, yes that's what I mean) when there are < ~10 k's left. The error would be extremely small as it relates to optimum sieve depth with this many k's left and only moderate even as it closes in on 10 k's remaining. Probably at < ~5-10 k's left, we'd want to look into their avg. weight vs. the avg. weight of the 10-20 k's that were eliminated just prior to the k's that are last remaining.

To clarify; n=25K-75K reduced the # of k's by 60% of the k's remaining at n=25K.

Extrapolating; n=75K-225 should reduce the # of k's by 60% of the k's remaining at n=75K.


Gary

[ValerieVonck]

will take : 76K-77K

[ValerieVonck]

so far, 1 prime found : 44433008*3^767074-1

[KEP]

Originally Posted by CedricVonck

so far, 1 prime found : 44433008*3^767074-1

Wow that was a "big prime" did you remember to add it to the top5000 pages

KEP!

[jasong]

reserving 77k-78k, llring across all cores of a Q6600(2.4GHz quadcore)

will post ETA in a few hours, since I want to work my BOINC queue down a bit.

[jasong]

The following are both probable primes:

68119208*3^77608-1
46511006*3^77655-1

[KEP]

Originally Posted by jasong

The following are both probable primes:

You have to verify the PRP primes using OpenPFGW -tp function

Regards

KEP