Double-checking with PFGW - Page 6

gd_barnes · 2010-09-21, 08:58

Quote:

Originally Posted by kar_bon

The candidates during testing k*b^b+1 were:

Code:

1000000006:P:1:619:1
9238 619
1000000006:P:1:626:1
9276 626
9876 626
1000000006:P:1:627:1
7504 627
8004 627
9056 627
9256 627
1000000006:P:1:635:1
9386 635
1000000006:P:1:650:1
8619 650
9732 650

What I've done was, comparing the results with LLR 3.8.1, pfgw 3.3.4 and pfgw 3.3.6 where I found errors with those pairs before.

Results:
- LLR 3.8.1: none of the candidates were found PRP/prime (ERROR: ROUND OFF for 9876*626^626+1)
- pfgw 3.3.4: same here, all composite
- pfgw 3.3.6: 9238*619^619+1 is 3-PRP, others composite

The Riesel-side I've not checked yet.

That is very different than what I got. Here it is:

PFGW 3.3.4:
9238*619^619+1 is composite: RES64: [AF5E2DAE777932BE] (0.1777s+0.0002s)
9276*626^626+1 is 3-PRP! (0.3916s+0.0004s)
9876*626^626+1 is composite: RES64: [B377446921E05347] (0.1782s+0.0030s)
7504*627^627+1 is composite: RES64: [F46DD144C5625090] (0.1808s+0.0003s)
8004*627^627+1 is composite: RES64: [44A8BD3280FB61E2] (0.1807s+0.0003s)
9056*627^627+1 is composite: RES64: [161BFF99F7AF07DC] (0.1780s+0.0003s)
9256*627^627+1 is composite: RES64: [58B08246F49CEAEC] (0.1778s+0.0003s)
9386*635^635+1 is 3-PRP! (0.1803s+0.0003s)
8619*650^650+1 is 3-PRP! (0.3837s+0.0023s)
9732*650^650+1 is 3-PRP! (0.1905s+0.0022s)

PFGW 3.3.6:
9238*619^619+1 is 3-PRP! (0.2151s+0.0002s)
9276*626^626+1 is 3-PRP! (0.2170s+0.0028s)
9876*626^626+1 is 3-PRP! (0.2176s+0.0020s)
7504*627^627+1 is 3-PRP! (0.2182s+0.0027s)
8004*627^627+1 is 3-PRP! (0.2194s+0.0026s)
9056*627^627+1 is 3-PRP! (0.2186s+0.0023s)
9256*627^627+1 is 3-PRP! (0.2253s+0.0020s)
9386*635^635+1 is 3-PRP! (0.2221s+0.0034s)
8619*650^650+1 is 3-PRP! (0.2340s+0.0029s)
9732*650^650+1 is 3-PRP! (0.2327s+0.0020s)

When applying the -t switch to both PFGW 3.3.4 and 3.3.6, all were found prime, as they should be.

You must be using different versions than 3.3.4 and 3.3.6 in your tests.

So we have 6 primes that were not identified as PRP by PFGW 3.3.4 but were identified as PRP by PFGW 3.3.6.

kar_bon · 2010-09-21, 09:11

Quote:

Originally Posted by gd_barnes

That is very different than what I got.

Sorry, mixed up the parameters. I forgot '-t' in pfgw here but done when I found those differences in pfgw V3.3.4, V3.3.6 and LLR.

Quote:

Originally Posted by gd_barnes

So we have 6 primes that were not identified as PRP by PFGW 3.3.4 but were identified as PRP by PFGW 3.3.6.

And none prime with LLR 3.8.1.

vmod · 2010-09-21, 09:13

Quote:

Originally Posted by gd_barnes

1. Without a Linux version, my testing is continuing with 3.3.4.

There is a linux pfgw 3.3.6 uploaded at SourceForge
http://sourceforge.net/projects/open...3.zip/download

gd_barnes · 2010-09-21, 09:45

Very good. Thanks Vmod.

rogue · 2010-09-21, 12:46

Quote:

Originally Posted by gd_barnes

1. Without a Linux version, my testing is continuing with 3.3.4.
2. We'll need to add R51 to n=3K as well as new bases that I've been running to n=25K that were done since the time that you made your list to the bases that need to be checked.
3. For lack of wanting to administer another effort here, I'm dragging my feet on keeping track of what's been done and is left to do. I'll likely get more motivated when a missing prime is found.

I posted this eight days ago. You must have missed it.

I have yet to find any primes for CRUS that were missed by PFGW 3.3.4. I found one that was missed by a version of PFGW prior to 3.3.4 (mentioned here), but would not have been missed by 3.3.4. I also mentioned here about Generalized Woodalls that I found when retested with PFGW 3.3.6. These would have been found by PFGW 3.3.4. They were tested a long time ago, most likely by PFGW 1.x.

Of course if I find any missed by CRUS, I will post it here.

rogue · 2010-09-23, 15:15

I have completed sieving for retesting of Sierpinski bases >= 800 and have some stats. Overall I am checking 64 bases. I need to retest about 0.91% of the tests, 7408 of 816,786. Using some of the Riesel data for stats I limited my sieving on the heaviest bases (928 and 999, which accounted for more than 600,000 of the above number), I was able to determine that the number of retests for those bases would be very low, so I sieved to about 1e9 for them, which saved me a lot of time. Most of the others were sieved to 1e10, which, as it turns out, was too high for them as well. I probably could have sieved to about 5e9 and would have been okay for most of the bases.

The base with the most tests was 928, with 510,105 tests after sieving, but that base only yielded 30 retests. I had three bases with 0 retests and a a number of other bases with less than 10. The base with the highest percentage of retests was 842, with 499 of 1257 (31.84%) needing to be retested. A couple of other bases had over 15%. I expect base 828 to take the longest to retest as there a number of n > 25,000 to retest. Base 920 has the most retests at 559.

An interesting thing to note is that R814 has a retest rate around 23%, but S814 is only about .25%. This implies to me that the value of k has a significant impact on FFT size selection.

I am about 60% through the resting of the Riesel side for bases >= 800. No new primes have been discovered. I hope to be finished with both sides for bases >= 800 next week.

Batalov · 2010-09-24, 20:32

It seems that it could be fun to build the experimental PFGW version with libgw 26.2 - many new granular FFT sizes, possibly faster in many conditions etc...

MyDogBuster · 2010-09-24, 20:46

Quote:

It seems that it could be fun to build the experimental PFGW version with libgw 26.2 - many new granular FFT sizes, possibly faster in many conditions etc...

LLR 3.8.2 WOW Maybe 10% faster.

Edit: 10% faster as advertised

rogue · 2010-09-24, 20:49

Quote:

Originally Posted by Batalov

It seems that it could be fun to build the experimental PFGW version with libgw 26.2 - many new granular FFT sizes, possibly faster in many conditions etc...

Already in progress. In fact I am working on a 64-bit build, which is even faster than the 32-bit build of v26.2.

vmod · 2010-09-26, 23:27

I've now double-checked S133, S148, S189, S917, S930 and R133, R148, R272 up to their current testing limit. All residues matched.

Only remaining from the bases I've worked on is R42. It's ok up to n=1000 and needs a double-check on ~18% of the tests (evenly distributed up to n=100K). I'll leave R42 double-check for the future or for someone else if willing. It's only recently I finished with >40,000 R42 tests so it would be boring to take it on right now.

rogue · 2010-09-27, 18:20

I have double-checked to n=40,000 for b>=800, both Sierpinski and Riesel. I have about 3500 tests to go. I have discovered no new primes.

I also double-checked remaining k to n=1,000 for all b>=100, both Sierpinski and Riesel. I discovered two mistakes on the webpages, but no new primes. I have notified Gary of the mistakes and they have been fixed.

I also double-checked remaining k on S63 to n=1,000. No new primes.

2010-09-23, 15:15	#61
rogue "Mark" Apr 2003 Between here and the 11·577 Posts	Sierpinski retest stats I have completed sieving for retesting of Sierpinski bases >= 800 and have some stats. Overall I am checking 64 bases. I need to retest about 0.91% of the tests, 7408 of 816,786. Using some of the Riesel data for stats I limited my sieving on the heaviest bases (928 and 999, which accounted for more than 600,000 of the above number), I was able to determine that the number of retests for those bases would be very low, so I sieved to about 1e9 for them, which saved me a lot of time. Most of the others were sieved to 1e10, which, as it turns out, was too high for them as well. I probably could have sieved to about 5e9 and would have been okay for most of the bases. The base with the most tests was 928, with 510,105 tests after sieving, but that base only yielded 30 retests. I had three bases with 0 retests and a a number of other bases with less than 10. The base with the highest percentage of retests was 842, with 499 of 1257 (31.84%) needing to be retested. A couple of other bases had over 15%. I expect base 828 to take the longest to retest as there a number of n > 25,000 to retest. Base 920 has the most retests at 559. An interesting thing to note is that R814 has a retest rate around 23%, but S814 is only about .25%. This implies to me that the value of k has a significant impact on FFT size selection. I am about 60% through the resting of the Riesel side for bases >= 800. No new primes have been discovered. I hope to be finished with both sides for bases >= 800 next week.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Double checking	gd_barnes	Riesel Prime Search	69	2021-03-21 00:54
Double Checking on GPU72	bayanne	GPU to 72	17	2013-12-25 18:16
What about double-checking TF/P-1?	137ben	PrimeNet	6	2012-03-13 04:01
Double checking	Unregistered	Information & Answers	19	2011-07-29 09:57
Double-checking milestone?	jobhoti	Math	17	2004-05-21 05:02

2010-09-21, 09:45	#59
gd_barnes May 2007 Kansas; USA 3³·5·7·11 Posts	Very good. Thanks Vmod.

2010-09-24, 20:32	#62
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 9476₁₀ Posts	It seems that it could be fun to build the experimental PFGW version with libgw 26.2 - many new granular FFT sizes, possibly faster in many conditions etc...

2010-09-26, 23:27	#65
vmod Mar 2010 Hampshire, UK 51₁₀ Posts	I've now double-checked S133, S148, S189, S917, S930 and R133, R148, R272 up to their current testing limit. All residues matched. Only remaining from the bases I've worked on is R42. It's ok up to n=1000 and needs a double-check on ~18% of the tests (evenly distributed up to n=100K). I'll leave R42 double-check for the future or for someone else if willing. It's only recently I finished with >40,000 R42 tests so it would be boring to take it on right now.

2010-09-27, 18:20	#66
rogue "Mark" Apr 2003 Between here and the 11·577 Posts	I have double-checked to n=40,000 for b>=800, both Sierpinski and Riesel. I have about 3500 tests to go. I have discovered no new primes. I also double-checked remaining k to n=1,000 for all b>=100, both Sierpinski and Riesel. I discovered two mistakes on the webpages, but no new primes. I have notified Gary of the mistakes and they have been fixed. I also double-checked remaining k on S63 to n=1,000. No new primes.