New srbsieve and related programs testing/fixes

[KEP]

Originally Posted by rogue

...If you still can't keep all worker threads busy, then you can append an 'f' to the value you pass in the -w thread, e.g. -w1e7f. This allows you to create chunks of work that take less than 1 second or more more than 5 seconds each...

Thanks for the hint, I'm not sure when, but after my current base 3 reservations complete, I will resume S383 and eventually R383 and after that I have to use srsieve2 on something new. I might be able to sieve a lot faster using the 'f' on the -w value, since sieving as little as 1000 primes per chunck is dreadfully slow especially when compared to sometimes for full throttle I had to use a value of 500,000 to 1,500,000 - wich gave almost 100% CPU utility

[rogue]

I have no clue how I messed that up because I ran a test and thought it generated the correct output. The code bug was obvious. I did revert the change for k, so that fbncsieve supports k=1.

[gd_barnes]

The lion's share of it looks correct but it has problems with base 2.

Small issue: k=1 is in the primes file for R2. Since 1*2^1-1 = 1, it should not be there. PFGW lists it as unity in its output file. I suppose you could either put it in the factors file as unity or drop it all together for R2 only.

Main problem: Both R2 and S2 are dropping all even k's. This is causing it to drop terms that should be there in both the factors and primes files.

Fbncsieve factor of 3 for R2 k<50:

3 | 5*2^1-1
3 | 11*2^1-1
3 | 17*2^1-1
3 | 23*2^1-1
3 | 29*2^1-1
3 | 35*2^1-1
3 | 41*2^1-1
3 | 47*2^1-1

PFGW factor of 3 for R2 k<50:

1*2^1-1 is Unity (1)
5*2^1-1 trivially factors as: 3^2
8*2^1-1 trivially factors as: 3*5
11*2^1-1 trivially factors as: 3*7
14*2^1-1 trivially factors as: 3^3
17*2^1-1 trivially factors as: 3*11
20*2^1-1 trivially factors as: 3*13
23*2^1-1 trivially factors as: 3^2*5
26*2^1-1 trivially factors as: 3*17
29*2^1-1 trivially factors as: 3*19
32*2^1-1 trivially factors as: 3^2*7
35*2^1-1 trivially factors as: 3*23
38*2^1-1 trivially factors as: 3*5^2
41*2^1-1 trivially factors as: 3^4
44*2^1-1 trivially factors as: 3*29
47*2^1-1 trivially factors as: 3*31

Fbncsieve primes for R2 k<50:

1 1
3 1
7 1
9 1
15 1
19 1
21 1
27 1
31 1
37 1
45 1
49 1

PFGW primes for R2 k<50:

2*2^1-1
3*2^1-1
4*2^1-1
6*2^1-1
7*2^1-1
9*2^1-1
10*2^1-1
12*2^1-1
15*2^1-1
16*2^1-1
19*2^1-1
21*2^1-1
22*2^1-1
24*2^1-1
27*2^1-1
30*2^1-1
31*2^1-1
34*2^1-1
36*2^1-1
37*2^1-1
40*2^1-1
42*2^1-1
45*2^1-1
49*2^1-1

Everything appears to match except that fbncsieve is missing even k's.

I checked for k's that were multiples of the base on other bases and it did not have this problem. There must be some special code in place that doesn't allow base 2 to consider even k's on either the Riesel or Sierpinski side.

Everything also seemed to work OK for bases 4, 8, and 16.

I did not have time to do much testing tonight so I'm having to stop with just this problem for base 2. I'll have more time later on Tuesday to test such things as large bases and huge k's and n's as well as various unusual exception situations.

[rogue]

For base 2 the code ignores even ks. I have debated the value of that change. I can easily remove it and leave it to end users to filter out even k for base 2.

I could change min k to 2 for base 2 and c = -1, but nobody would use the code to sieve it.

[gd_barnes]

Originally Posted by rogue

For base 2 the code ignores even ks. I have debated the value of that change. I can easily remove it and leave it to end users to filter out even k for base 2.

I could change min k to 2 for base 2 and c = -1, but nobody would use the code to sieve it.

It must be removed for incorporation into srbsieve. What if someone wants to run the 3rd or 4th or 5th conjecture for R2 or S2? They couldn't account for all even k's with the code that is currently in there. Regardless it should be consistent across all bases.

As for stand-alone running of fbncsieve, I feel that the user should be able to decide whether they want k's that are a multiple of the base in there regardless of what base it is. The program should not decide for them.

I would not change the min k for base R2. k=1 should be allowed for R2 k=1 & n=(something huge) just like all other bases. If n>1 then its result can go to the factor file or sieve file like its normal process. If n=1 then do a special process. It could be thrown out or written to a "unity" line in the factor file like PFGW does in its output. By writing the unity line in the factor file, you effectively account for all k's so that there is a total of 10,000 lines combined written for a k-range of 1-10,000 in the factor plus sieve files. At the moment, that is what happens on all even bases except for base 2.

[rogue]

Originally Posted by gd_barnes

It must be removed for incorporation into srbsieve. What if someone wants to run the 3rd or 4th or 5th conjecture for R2 or S2? They couldn't account for all even k's with the code that is currently in there. Regardless it should be consistent across all bases.

As for stand-alone running of fbncsieve, I feel that the user should be able to decide whether they want k's that are a multiple of the base in there regardless of what base it is. The program should not decide for them.

I would not change the min k for base R2. k=1 should be allowed for R2 k=1 & n=(something huge) just like all other bases. If n>1 then its result can go to the factor file or sieve file like its normal process. If n=1 then do a special process. It could be thrown out or written to a "unity" line in the factor file like PFGW does in its output. By writing the unity line in the factor file, you effectively account for all k's so that there is a total of 10,000 lines combined written for a k-range of 1-10,000 in the factor plus sieve files. At the moment, that is what happens on all even bases except for base 2.

I have modified fbncsieve to change mink from 1 to 2 for R2, but it gives a message when it does that. I have also modified fbncsieve to not remove even k for base 2. srbsieve will support k=1 for R2, but will not remove for n=1.

fbncsieve only removes odd k for odd bases. Use of -r can remove k where k % base = 0. So if someone wants to remove even k for base 2, then can use -r to do it. srbsieve no longer passes -r to fbncsieve.

[rogue]

Outside of the other changes that have been mentioned, the biggest change is what happens if a number that is PRP turns out to be composite during the primality test. These composites be written to a file called pl_unknown.txt and srbsieve will not test those k further. This means that you will need to test those k externally to srbsieve to find the smaller prime for them. The changes of this are extremely small.

[storm5510]

Originally Posted by rogue

Outside of the other changes that have been mentioned, the biggest change is what happens if a number that is PRP turns out to be composite during the primality test. These composites be written to a file called pl_unknown.txt and srbsieve will not test those k further. This means that you will need to test those k externally to srbsieve to find the smaller prime for them. The changes of this are extremely small.

This latest seems to function properly.

fbncsieve is a different story. All of the v1.6.3 versions fail within srbsieve. v1.6.1 runs alright. I never saw a v1.6.2 if it ever existed. I have so many versions downloaded here that I cannot tell them apart. Perhaps an extra digit might help, e.g. 1.6.3.1 for example. Each modification would increase the last digit. Why? Reverting to a working previous version.

[rogue]

The fbncsieve versions posted here are "alpha" versions. I will post a beta in the mtsieve thread this week.

[Happy5214]

Originally Posted by gd_barnes

It must be removed for incorporation into srbsieve. What if someone wants to run the 3rd or 4th or 5th conjecture for R2 or S2? They couldn't account for all even k's with the code that is currently in there. Regardless it should be consistent across all bases.

For the record, I've already started on the 3rd and 4th conjectures for R2. The 3rd conjecture has 4 k's left (progress on the Prime-Wiki at https://www.rieselprime.de/ziki/Riesel_problem_3rd), while the 4th conjecture only has k=780427 remaining (I only tested to n=500k, but it was previously tested to n=1.0M by Gary). I can post all that data once I get the 3rd conjecture to n=1.0M (which may or may not be any time soon, since I just did an OS upgrade and have to reinstall the database I use for PRPNet).

And, as an aside, given all the breaking changes in srbsieve, I would have bumped the version to 2.0 rather than 1.4.

[henryzz]

Originally Posted by Happy5214

And, as an aside, given all the breaking changes in srbsieve, I would have bumped the version to 2.0 rather than 1.4.

Maybe the alpha/beta versions could be 1.4 and the final version 2.0.

Would probably suggest releasing new versions as release candidates currently until we have some confidence in them.