News

[KEP]

Originally Posted by gd_barnes

I have added some useful info. to our main...2 conjecture that is being worked on by PrimeGrid.

I've cut the quote to save space

Great work Gary. In the wake of the almost if not total loss of data when the datacenter of the SoB conjecture apparently burned down, it sure has been a concern of mine how to secure our data. A lot of effort has gone in to producing these data. Your described effort, sure will make our data sort of backed up

You may consider, in the software thread to reference to srbsieve, it is much faster and for millions of small primes, much more reliable since these primes are found using fixed n, fixed b, fixed c and variable k sieving. I for the R3 effort used good old NewPGen going up to n=17 (If I recall correctly) so all primes n<=17 should be legit.

When creating your proofs, you should consider using srbsieve to find the Trivial, MOB and if needed small primes. Especially for the big conjectures there is littlerally years of effort to save, when comparing srbsieve with the starting bases script and even for the big k's a sieved prime is in fact prime, not PRP or pseudo or anything else, it IS prime

I'm willing to offer you some help in PM on how to use srbsieve if needed - srbsieve is very easy to use

[gd_barnes]

I have moved the discussion about srbsieve to the Software thread here:

https://mersenneforum.org/showthread.php?t=9742

[gd_barnes]

I have now added links for an accounting of all k's for all of the power-of-2 bases. Bases 16 and 256 were fairly tricky to run down all of the primes.

Next I'll probably do many of the proven bases.

[gd_barnes]

I made some changes to the reservations pages to better standardize the wording around our sieve files and to provide better additional info. on k's remaining. Changes made:

1. Changed "in process" to "in progress" on the bases where testing/sieve files are being corrected. [Although it is a process, the corrections are actually in progress. :-) ]

2. Changed "Sieve file (additional sieving needed):" to "Partially sieved file:" mostly related to partial n=2.5K-10K sieves. [Standardized with the wording around partially sieved files for other n-ranges.]

3. Removed "Fully sieved file:" exclusively related to n=2.5K-10K sieves. [This was redundant and inconsistent with fully sieved files for other n-ranges. If a sieve file does not show "Partially sieved file:" then it can be assumed to be fully sieved as can be best deduced by others or me.]

4. Added a k's remaining file if there is not a link to a k's remaining page and there is not a posted sieve file. [This was mainly related to bases tested to n=2.5K where I don't create a k's remaining page -and- the sieve file is either too big to post or there is no sieve file.]

Reference #3: If a file is sieved to P<5e14 then you can assume that it was not sieved by Yoyo and might want to check to see if additional sieving would be beneficial even if it doesn't show as partially sieved. Sieving and testing software and GPUs/CPUs are continually being updated, which can result in continually changing optimum sieve depths as time goes along.

Reference #4: You should be able to see the k's remaining on all bases now. If they have > 25 k's remaining, on the reservations page there will either be the usual link to a k's remaining page, the k's will be in a sieve file, or there will be a link to a text file of k's remaining.

[gd_barnes]

As a result of testing for our new srbsieve software, two problems have come to light with various programs here at CRUS:

1. PFGW all versions in the last 10+ years will incorrectly identify primes between about 1e12 and 1.1e12 as factored, hence composite. Such primes are initially found as PRP but fail in the primality proving process.

2. Srsieve2 will incorrectly remove all n-values in its algebraic factoring process on Riesel bases that are a perfect power and where the k is a different perfect power than the base. Sierpinski bases are not affected.

*****

Suggestions:

*****

PFGW:
The last version that I'm aware of that doesn't have the problem is 3.3.6 from Sept. 2010. I don't suggest reverting to such an old program. I had previously suggested in a couple of places to revert to version 3.7.7. That won't work as it will likely have the problem also.

Mark (rogue) is working on the problem and will hopefully have a new release for us later this week.

Since this only affects a small range of specifically 13-digit primes, I would suggest going ahead and using PFGW 4.0.x because most of our work is on longer tests.

For potentially smaller testing:

If running the starting bases script for new bases, it will trial factor composite PRP's to 1e8. This is enough to prove 13-digit numbers as prime. So there will not be a problem.

If doing testing with the new srbsieve, set maxNfbncsieve to a high enough level so that the runs of fbncsieve are sieving everything up through 13 digits. Setting it to n=5 for bases > 300, n=7 for bases 100-300, n=10 for bases 20-99, etc. would be enough. The only bases < 20 still partially untested are bases 7 and 15. You would need to do your own calculation on those.

If doing other random testing on small numbers where you are running PFGW, consider using LLR if possible for the time being.

Other than the problem with small tests, newer versions of PFGW should be OK unless you hear otherwise from Mark.

*****
Srsieve2:
If sieving the Sierpinski side, there are no problems.

If sieving the Riesel side, if the base is a perfect square, then you should likely stop and evaluate the situation. Determine if there are any k's remaining that are a perfect cube or high power. Here is an example that alerted me to the problem:

1744*25^139-1 is prime. This eliminates k=1744 for R25. But if you were starting the base from scratch today with srbsieve, it would not find the prime. Here is why: After work is done on small n's, srbsieve uses srsieve2 for sieving. When running srsieve2 to sieve 1744*25^n-1 for n=1 to 200 or 1000 or any value > 1, it incorrectly removes all terms as having algebraic factors.

Reason:
Base 25 is 5^2. k=1744 is 14^3. In other words, the base is a square and the k is a cube. Srsieve2 has a problem with this.

At this point, only squared bases are affected. I did a quick analysis on cubed/5th power/7th power bases and found none to be affected.

Many of our squared bases have been proven but there are still quite a few that are open. Many won't have any cubed or higher-power k's remaining. So our hope is that the impact is minimal.

If you are not feeling comfortable about this, consider switching to an older version of srsieve/sr2sieve before the removal of algebraic factorizations was introduced. It's OK if such factors are left in a sieve for the time-being. They can be manually removed later on.

If you have any questions about any Riesel squared base that you are sieving using srsieve2, let us know and we will be glad to look at the base and k's remaining.

[rogue]

Originally Posted by gd_barnes

1744*25^139-1 is prime. This eliminates k=1744 for R25. But if you were starting the base from scratch today with srbsieve, it would not find the prime. Here is why: After work is done on small n's, srbsieve uses srsieve2 for sieving. When running srsieve2 to sieve 1744*25^n-1 for n=1 to 200 or 1000 or any value > 1, it incorrectly removes all terms as having algebraic factors.

Reason:
Base 25 is 5^2. k=1744 is 14^3. In other words, the base is a square and the k is a cube. Srsieve2 has a problem with this.

This is the first I have heard of this. Definitely an issue and something that I have to fix.

[gd_barnes]

Mark has fixed the problem with srsieve2 where it incorrectly removes some terms with algebraic factors where none are present.

The new version misses some algebraic factors on Riesel bases where both k & base are squares or cubes or other higher power but such k's would be excluded from the conjectures at CRUS due to full algebraic factors. At the worst if you end up attempting to sieve them, you might end up primality testing the very few terms that would remain.

I'm sure he will look into the minor issue but it isn't nearly as pressing.

The new version is 1.7.1. It can be found in the latest mtsieve suite of programs at Sourceforge. If sieving with srsieve2, please upgrade as soon as you can.

[gd_barnes]

srsieve2 1.7.3 has been posted. After a fair amount of testing, it is apparent that all algebraic factor issues have been resolved. Please download it when you can.

[gd_barnes]

I have brought everything together for base R15 for k<=10M. There is now an "all k's" file link on the main CRUS Riesel page.

For the time being for the large-conjectured bases, I'm only posting files accounting for all k's <= 10M. Even with that restriction, the file is ~55 MB or ~14.4 MB zipped. At some point, we will do something different for the huge conjectures.

I will be doing the same for R7, S7, and S15. After that, I'll move on to bases R3 and S3. Then on to R31 and S31.

That will cover everything for bases <= 32, which was the original scope of the project. After that the focus will be on smaller conjectures.

[gd_barnes]

I have completed accounting for all k's for all bases < 35. For conjectures > 10M, an accounting for only k's <= 10M was done.

The "all-ks" file links are on the pages.

This completes this effort for the original project, which included bases <= 32.

From time to time, I'm working my way up by base for only conjectures < 10000. The files will be posted as they are finished.

[gd_barnes]

I no longer need the pl_trivial files on new bases. A copy-paste of the balancing of all of the k's by the srbverify program is sufficient

The files are increasingly big for the ever larger conjectures that we are now doing and are a nuisance to send through Email or by other means.

It's trivial for me to create them on my end. (pun intended)