Bad sieve files found for 2020 and 2021 - Page 2

Luminescence · 2022-09-09, 11:50

Quote:

Originally Posted by gd_barnes

I sieved R88 19 k's for n=250K-500K on a few cores up to P=200e9.

I'm now running 20 threads on my Ryzen 3950X. It will be at 5e12 in ~10 hours.

Florian, can you make a sieve for R88 for the 19 k's for n=250K-500K up to 5e12 ? Optionally you could just sieve it quickly to P=200e9. Either way, we can then compare files.

I'm assuming that you are familiar with sieving. If not, no big deal. This is just an additional check that we can do.

I'll be signing off shortly.

I can do that. I will be doing one file up to 200e9 and one to 5e12 with srsieve2 (newest version). There is still the thread with instructions for sieving.

I could also remove the automatic algebraic factoring from the code of srsieve2 to see if it produces incorrect results. It seems like a trivial thing to do.

gd_barnes · 2022-09-09, 11:52

Quote:

Originally Posted by Luminescence

I can do that. I will be doing one file up to 200e9 and one to 5e12 with srsieve2 (newest version). There is still the thread with instructions for sieving.

I could also remove the automatic algebraic factoring from the code of srsieve2 to see if it produces incorrect results. It seems like a trivial thing to do.

Much appreciated. Thanks!

VBCurtis · 2022-09-09, 14:32

I don't think you need to go as far as re-testing all the candidates for primality. Once the new sieves are reasonably deep, compare to the file that was tested for primality, and then run primality tests on all the candidates still in the new sieve that weren't already tested.

You have good reason to trust the primality testing side of the project, so double-checking the entire range should be put off until after the sieve stuff is investigated.

I suppose you might also double-check the first 1% of a range and compare residues, just in case there are mismatches.

The bug mentioned in the sieve software "should" only affect really small candidates- the sieve has no way to know which candidates are prime, unless the sieve depth reaches sqrt of a candidate. So, primes with exponent below 100 could possibly be removed from a sieve rather than reported prime, but not in the ranges you're considering here.

Of course, if I'm wrong then we have a new *really* fast way to find primes with just a sieve!!!

gd_barnes · 2022-09-09, 21:04

Great points, Curtis! Thanks for the thoughts.

Florian just sent me his files sieved to P=200G and 5e12. Mine just finished to 5e12. In a little while, I'll remove the factors and compare them.

Perhaps we can just re-run the lower 20% of the range for R88 n=250K-300K plus all candidates that are in our file sieved to 5e12 that are not in the file sieved to 5e14. That would be a lot less time-consuming and give us ~20000 k/n pairs to compare residues.

That makes sense about it removing candidates at the lower end of a sieve-range that are prime. NewPGen had that issue. I'm glad that was fixed but it should not affect us.

gd_barnes · 2022-09-10, 08:17

I have compared the sieves that I did with sr2sieve and the sieves that Florian did with srsieve2. Oddly srsieve2 is missing some factors that were found by sr2sieve but it does not appear to have produced any extra factors that would cause a candidate to be removed incorrectly. All of these missed factors were for k=1247, which happens to be the smallest k in the file out of 19 k's.

There were 43 more factors in the sieve done with sr2sieve vs. the one using srsieve2 at P=2e11, all for k=1247. There were 58 extra factors at P=5e12. Apparently srsieve2 continued to miss factors.

I want to do more detailed analysis but I won't have time until later on Saturday. Here are a few notes:

1. I did some spot check with 4-5 of the factors produced by sr2sieve that were missed by srsieve2 using the FactorDB. They are correct factors.

2. Due to time constraints, I have not yet done a direct compare of the files for other k's because all the counts matched. It's always possible that there could be differences even though the counts are the same.

3. This is more complex than it appears at first glance. In several instances, sr2sieve found a factor that was missed by srsieve2. But then later on srsieve2 found a larger factor to eliminate the same k/n pair making the difference in factor count less than it should be. So the number of missed factors is actually somewhat larger than shown above.

4. The newest version of srsieve2 is unlikely to be the version that was primarily used in the original sieve of this file that produced no primes. So this may not get us anywhere. But it looks like it may highlight some current issues with srsieve2.

I will do a more direct compare of things later on Saturday.

gd_barnes · 2022-09-12, 11:09

Florian and I have been coordinating on re-sieving R88 for n=250K-500K. I have finished sieving it to P=25e12 using only srsieve followed by sr2sieve. I am keeping every factor found for P>1e9 for the effort.

Currently there are 108,091 tests in our file at P=25e12. There were 98,687 tests in the Yoyo file at P=500e12, which is what SRBase tested with. A difference of 9404 tests. That difference is a little low but is mostly within the margin of error of predicted factors by sr2sieve, which predicts 9567.31 factors for P=25e12 to 500e12.

Originally I was thinking of suggesting that SRBase test the difference in k/n pairs at this point. But we are considering sieving it further while continuing to keep a detailed accounting of the factors found.

rebirther · 2022-10-16, 12:43

Iam rerunning R88_250-300k on SRBase with the new llr2 app for double checking, unfortunately the app is 400s slower on my CPU than llr3.8.21. Should take a month or less if nothing happens again.

gd_barnes · 2022-10-16, 18:50

Quote:

Originally Posted by rebirther

Iam rerunning R88_250-300k on SRBase with the new llr2 app for double checking, unfortunately the app is 400s slower on my CPU than llr3.8.21. Should take a month or less if nothing happens again.

Sorry I've only had a small amount of time to look into this issue.

That's a good start. As residues come out, you can do a compare on them.

I also have a file sieved by Luminescence and me to P=1e14 (mostly by him) where I've been able to verify that all of the factors removed were good. The original file that SRBase tested with was sieved to 5e14. After you are done with 250k-300k, what we can do is test the candidates that are in our new file that are not in the one that was sieved more deeply.

We are looking for two verifications here:
1. The residues match.
2. The original sieve file is good.

rebirther · 2022-11-04, 16:42

Quote:

Originally Posted by gd_barnes

Sorry I've only had a small amount of time to look into this issue.

That's a good start. As residues come out, you can do a compare on them.

I also have a file sieved by Luminescence and me to P=1e14 (mostly by him) where I've been able to verify that all of the factors removed were good. The original file that SRBase tested with was sieved to 5e14. After you are done with 250k-300k, what we can do is test the candidates that are in our new file that are not in the one that was sieved more deeply.

We are looking for two verifications here:
1. The residues match.
2. The original sieve file is good.

The dc is done with llr2, less then 170 results were not matched in residues and no prime was found.

gd_barnes · 2022-11-22, 00:41

For R88, we are currently double-checking the n=300k-350k range -and- first-time testing of candidates that were sieved out between P=100e12 and 500e12 for the entire n=250k-500k range.

No missing primes were found in the original n=250k-300k range.

This should be a sufficient double-check for R88.

Over the next several months, we will put together a plan to double-check a portion of all of the bases in 2022 that had 2 k's remaining and no primes for n=300k-500k.

rebirther · 2022-11-22, 16:35

Quote:

Originally Posted by gd_barnes

For R88, we are currently double-checking the n=300k-350k range -and- first-time testing of candidates that were sieved out between P=100e12 and 500e12 for the entire n=250k-500k range.

No missing primes were found in the original n=250k-300k range.

This should be a sufficient double-check for R88.

Over the next several months, we will put together a plan to double-check a portion of all of the bases in 2022 that had 2 k's remaining and no primes for n=300k-500k.

R88 250-500k testing range complete, no primes found, 300-350k double check range matching all residues with the first run

If you have another important base to double check where a prime is expected but doesnt find anything let me know.

2022-09-09, 21:04	#15
gd_barnes "Gary" May 2007 Overland Park, KS 2·19·317 Posts	Great points, Curtis! Thanks for the thoughts. Florian just sent me his files sieved to P=200G and 5e12. Mine just finished to 5e12. In a little while, I'll remove the factors and compare them. Perhaps we can just re-run the lower 20% of the range for R88 n=250K-300K plus all candidates that are in our file sieved to 5e12 that are not in the file sieved to 5e14. That would be a lot less time-consuming and give us ~20000 k/n pairs to compare residues. That makes sense about it removing candidates at the lower end of a sieve-range that are prime. NewPGen had that issue. I'm glad that was fixed but it should not affect us. Last fiddled with by gd_barnes on 2022-09-10 at 05:04

2022-09-10, 08:17	#16
gd_barnes "Gary" May 2007 Overland Park, KS 12046₁₀ Posts	I have compared the sieves that I did with sr2sieve and the sieves that Florian did with srsieve2. Oddly srsieve2 is missing some factors that were found by sr2sieve but it does not appear to have produced any extra factors that would cause a candidate to be removed incorrectly. All of these missed factors were for k=1247, which happens to be the smallest k in the file out of 19 k's. There were 43 more factors in the sieve done with sr2sieve vs. the one using srsieve2 at P=2e11, all for k=1247. There were 58 extra factors at P=5e12. Apparently srsieve2 continued to miss factors. I want to do more detailed analysis but I won't have time until later on Saturday. Here are a few notes: 1. I did some spot check with 4-5 of the factors produced by sr2sieve that were missed by srsieve2 using the FactorDB. They are correct factors. 2. Due to time constraints, I have not yet done a direct compare of the files for other k's because all the counts matched. It's always possible that there could be differences even though the counts are the same. 3. This is more complex than it appears at first glance. In several instances, sr2sieve found a factor that was missed by srsieve2. But then later on srsieve2 found a larger factor to eliminate the same k/n pair making the difference in factor count less than it should be. So the number of missed factors is actually somewhat larger than shown above. 4. The newest version of srsieve2 is unlikely to be the version that was primarily used in the original sieve of this file that produced no primes. So this may not get us anywhere. But it looks like it may highlight some current issues with srsieve2. I will do a more direct compare of things later on Saturday. Last fiddled with by gd_barnes on 2022-09-10 at 08:19

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
RSP Sieve Files for k*2^n-1 from PrimeGrid	pinhodecarlos	Riesel Prime Search	103	2022-11-26 15:02
Largest k*2^n-1 Primes Found In 2020	andyhedges	Riesel Prime Search	5	2021-01-02 00:09
I found a sieve to search all pairs of twin primes	Pietro Maiorana	Twin Prime Search	8	2019-09-26 23:07
Algebraic factors in sieve files	pepi37	Conjectures 'R Us	95	2017-07-04 13:37
program to verify factors found by sr(x)sieve?	mdettweiler	Software	16	2009-03-08 02:06

2022-09-09, 14:32	#14
VBCurtis "Curtis" Feb 2005 Riverside, CA 5729₁₀ Posts	I don't think you need to go as far as re-testing all the candidates for primality. Once the new sieves are reasonably deep, compare to the file that was tested for primality, and then run primality tests on all the candidates still in the new sieve that weren't already tested. You have good reason to trust the primality testing side of the project, so double-checking the entire range should be put off until after the sieve stuff is investigated. I suppose you might also double-check the first 1% of a range and compare residues, just in case there are mismatches. The bug mentioned in the sieve software "should" only affect really small candidates- the sieve has no way to know which candidates are prime, unless the sieve depth reaches sqrt of a candidate. So, primes with exponent below 100 could possibly be removed from a sieve rather than reported prime, but not in the ranges you're considering here. Of course, if I'm wrong then we have a new really fast way to find primes with just a sieve!!!

2022-09-12, 11:09	#17
gd_barnes "Gary" May 2007 Overland Park, KS 2·19·317 Posts	Florian and I have been coordinating on re-sieving R88 for n=250K-500K. I have finished sieving it to P=25e12 using only srsieve followed by sr2sieve. I am keeping every factor found for P>1e9 for the effort. Currently there are 108,091 tests in our file at P=25e12. There were 98,687 tests in the Yoyo file at P=500e12, which is what SRBase tested with. A difference of 9404 tests. That difference is a little low but is mostly within the margin of error of predicted factors by sr2sieve, which predicts 9567.31 factors for P=25e12 to 500e12. Originally I was thinking of suggesting that SRBase test the difference in k/n pairs at this point. But we are considering sieving it further while continuing to keep a detailed accounting of the factors found.

2022-10-16, 12:43	#18
rebirther Sep 2011 Germany 3,469 Posts	Iam rerunning R88_250-300k on SRBase with the new llr2 app for double checking, unfortunately the app is 400s slower on my CPU than llr3.8.21. Should take a month or less if nothing happens again.

2022-11-22, 00:41	#21
gd_barnes "Gary" May 2007 Overland Park, KS 2×19×317 Posts	For R88, we are currently double-checking the n=300k-350k range -and- first-time testing of candidates that were sieved out between P=100e12 and 500e12 for the entire n=250k-500k range. No missing primes were found in the original n=250k-300k range. This should be a sufficient double-check for R88. Over the next several months, we will put together a plan to double-check a portion of all of the bases in 2022 that had 2 k's remaining and no primes for n=300k-500k.