Starting new bases
 

[B]Admin edit: For starting new bases, it is recommended that the below PFGW scripts for new bases [/B][B]be used as input to PFGW. There are 2 different versions. One for PFGW 3.2.3 and earlier and one for PFGW 3.2.7 and later. Running the later version is highly recommended. For the latest PFGW version, see the "PFGW latest well tested version" thread.[/B]

PFGW 3.2.3 and earlier: [URL="http://www.noprimeleftbehind.net/crus/new-bases-4.1.txt"]new-bases-4.1[/URL]
PFGW 3.2.7 and later: [URL="http://www.noprimeleftbehind.net/crus/new-bases-4.3.txt"][COLOR=#0066cc]new-bases-4.3[/COLOR][/URL]

I've been searching these forums for several days now, and as a result my head hurts and it is yelling "too much information". I just need to find the answer to some simple questions:

Say for example I want to start some random base in Sierpinski or Riesel.

How do you:

1. Find out whether this base already has been tested and how far, who reserved it ect, ...
2. If nobody is working on it or has been working on it how do you find the conjecture with its covering set?
3. How do you start sieving files, which programs do you use ect ...
4. What should you use to test the remaining n? (or k). I did some small tests with newpgen to run the sieve and llr to test the remaining n and all I got was "ERROR!!" as a result of my effort :)

[quote=MrOzzy;142526]
Say for example I want to start a some random base in Sierpinski or Riesel.

How do you:

1. Find out wether this base already has been tested and how far, who reserved it ect, ...
2. If nobody is working on it or has been working on it how do you find the conjecture with its covering set?
3. How do you start sieving files, which programs do you use ect ...
4. What should you use to test the remaining n? (or k).)[/quote]
I would like to know this too. :smile:

[quote=MrOzzy;142526]I've been searching these forums for sevral days now, and as a result my head hurts and it is yelling "too much information". I just need to find the answer to some simple questions:

Say for example I want to start a some random base in Sierpinski or Riesel.

How do you:

1. Find out wether this base already has been tested and how far, who reserved it ect, ...
2. If nobody is working on it or has been working on it how do you find the conjecture with its covering set?
3. How do you start sieving files, which programs do you use ect ...
4. What should you use to test the remaining n? (or k). I did some small tests with newpgen to run the sieve and llr to test the remaining n and all I got was "ERROR!!" as a result of my effort :)[/quote]

1) Check out [URL]http://noprimeleftbehind.net/crus/Riesel-conjectures.htm[/URL]
2a) Run a black box program that calculates it for you. In the Crus forum there is the program by R. Gerbicz. Or you can ask me for a copy of mine.
2b) Or sieve a range of your base in srsieve and then the one that is discarded may be a Riesel or Sierpinski
2c) Or figure out how to find them yourself (not easy)
3a) First do a run with PFGW to dispose of all the small primes (see attached script)
3b) Then sieve the remaining k with srsieve
4) when you have sieved deep enough, switch to LLR or phrot.

Enjoy, Willem.

[QUOTE=Siemelink;142608]1) Check out [url]http://gbarnes017.googlepages.com/Riesel-conjectures.htm[/url]
2a) Run a black box program that calculates it for you. In the Crus forum there is the program by R. Gerbicz. Or you can ask me for a copy of mine.
2b) Or sieve a range of your base in srsieve and then the one that is discarded may be a Riesel or Sierpinski
2c) Or figure out how to find them yourself (not easy)
3a) First do a run with PFGW to dispose of all the small primes (see attached script)
3b) Then sieve the remaining k with srsieve
4) when you have sieved deep enough, switch to LLR or phrot.

Enjoy, Willem.[/QUOTE]

Thanks for your answers. I have a few more questions though:

2a) This program by R. Gerbicz (covering.exe) requires an exponent. What is the meaning of this exponent?
3a) How is PFGW related to that attached script?
3b) How do you know if you have sieved deep enough
4) How should you determine if you should use LLR or phort?

One of the reasons I ask this questions is to lower the step for people interested. Sooner or later a sticky topic with the needed info could be handy and interesting for potential sievers or prime hunters.

[QUOTE=MrOzzy;142657]Thanks for your answers. I have a few more questions though:

2a) This program by R. Gerbicz (covering.exe) requires an exponent. What is the meaning of this exponent?
3a) How is PFGW related to that attached script?
3b) How do you know if you have sieved deep enough
4) How should you determine if you should use LLR or phort?

One of the reasons I ask this questions is to lower the step for people interested. Sooner or later a sticky topic with the needed info could be handy and interesting for potential sievers or prime hunters.[/QUOTE]

2a) I forgot. Experiment with the program so that you can find known values.
3a) pfgw.exe scr.txt -f100 on the command line
3a) winpfgw.exe and then enter scr.txt -f100 in windows
3b) when the removal rate per minute is lower then what you get with LLR
4) Use LLR.

Willem.

I'm sorry I haven't had much time lately. These are great questions and Willem referred you to both the correct link with instructions and did a good job of answering them.

Starting new bases is EXTREMELY tricky and in the instructions that I prepared that he provided the link to, I suggested that you contact me when starting a new base. But Willem is now a resident expert in starting them and I'm glad he stepped in.

I realize that starting new bases is fun and interesting but my preference is that people search for bases <= 32 or bases that are powers of 2 up to 256.

If you can tell Willem or me what base you are interested in starting, we could give you the particular details and pitfalls of that particular base. Suggestion: When starting out, find a base with a relatively low conjecture.

As for the exponent, I suggest using either 24 or 144 most of the time. The exponent refers to how many n-values it takes before the covering set of factors repeats. For instance, if a k for a base has the following factors for the following modulos of n:

n : factor
(0 mod 4) : 5
(1 mod 4) : 3
(2 mod 4) : 7
(3 mod 4) : 3

It would be said to have a 'period' (or in the case of the "covering" program...'exponent'), of 4 because the factors repeat every 4 n-values.

Don't concern yourself if you don't get the math here, I'd just suggest using an exponent of 24 or 144.


Gary

Thanks for all the info.

I've been playing around with everything a little bit and I have a few more questions:

- This pgfw script seem to be made for Sierpinski only, is there a Riesel one available too?
- covering.exe you a conjectured K and the primes considered to calculate the conjectured K, but it doesn't tell which primes are used when a solution is found. How do I calculate which primes are used for the covering set?

[QUOTE=MrOzzy;143860]Thanks for all the info.
- This pgfw script seem to be made for Sierpinski only, is there a Riesel one available too?
[/QUOTE]

Change a plus into a minus where apropriate.

[quote=MrOzzy;143860]Thanks for all the info.

I've been playing around with everything a little bit and I have a few more questions:

- covering.exe you a conjectured K and the primes considered to calculate the conjectured K, but it doesn't tell which primes are used when a solution is found. How do I calculate which primes are used for the covering set?[/quote]


I think covering.exe gives a set of them that it used but those are almost always way more factors than what is needed and is not what we're looking for. What I generally do is do it manually by going to:
[URL]http://www.alpertron.com.ar/ECM.HTM[/URL]. It is a great program that will prime factor large numbers up to 10000 digits.

I plug in the form and try n=1, 2, 3, etc. I then analyze the least set of factors that makes them all composite. You have to be careful because it's easy to get a factor in there that you don't need. To be mathematically correct, we want the smallest covering set that makes the conjectured k always composite.

To get a good feel for it, play around with a known small conjecture such as Riesel base 8 with a (now proven) conjecture of k=14 and a covering set of [3, 5, 13]. See how the pattern of factors repeats for 14*8^n-1 with the different n-values. Once you do that, you should be able to do it with any base.

Covering.exe is pretty good at coming up with the lowest conjecture if it is given reasonable parameters. It's not so good at coming up with the smallest covering set.


Gary

I was playing around a little bit with everything and I got this when I ran srsieve using the output from pgfw: "removed candidate sequence 30*117^n-1 from the sieve"
.. but it doesn't say why ...

Hi! can anyone please explain what covering does???

I plugin following numbers:

[CODE]
104
2
-1
500000
3 5 13
Checking k*2^n-1 sequence for exponent=104, bound for primes in the covering set
=500000, bound for k is 3
Examining primes in the covering set: 3,5,17,8191,2731,53,157,1613
And their orders: 2,4,8,13,26,52,52,52[/CODE]

Base = 104
2 = exponent
-1 = Riesel
500000 = k ??
??

Thank you!

[quote=MrOzzy;144710]I was playing around a little bit with everything and I got this when I ran srsieve using the output from pgfw: "removed candidate sequence 30*117^n-1 from the sieve"
.. but it doesn't say why ...[/quote]


k=30 has a trivial factor of 29 for all n-values for Riesel base 117. Hence any sieving quickly eliminates all possible candidates.

For this base, all k==(1 mod 2), which has a trivial factor of 2, and k==(1 mod 29), which has a trivial factor of 29, would not be considered in the conjecture.

Whenever srsieve eliminates a candidate sequence, there is always some trivial set of factors or factor that make all n-values composite. We don't consider the k's where only one factor make all n-values composite. But if it is more than one, the smallest k-value would be the conjectured k-value until proven.


Gary

[quote=CedricVonck;144717]Hi! can anyone please explain what covering does???

I plugin following numbers:

[code]
104
2
-1
500000
3 5 13
Checking k*2^n-1 sequence for exponent=104, bound for primes in the covering set
=500000, bound for k is 3
Examining primes in the covering set: 3,5,17,8191,2731,53,157,1613
And their orders: 2,4,8,13,26,52,52,52[/code]

Base = 104
2 = exponent
-1 = Riesel
500000 = k ??
??

Thank you![/quote]


I believe you are asking what the covering.exe program does. Correct?

If so, it attempts to determine the lowest k-value that makes all n-values composite, which is what we call the 'conjectured k-value'. k-values with a single trivial factor for all n-values are excluded.

I believe you have mixed up the entries for the program and so it was spitting out info. for base 2.

The first entry is the 'exponent', which represents the 'period' in which a covering set of factors could repeat. I would generally suggest using 24, 72, or 144 for that. There's no way to know specifically but any relatively low value < 200 with a lot of factors of 2's and 3's is a good choice.

The second entry is the base (b) in the form k*b^n-1 or k*b^n+1. You chose 2 in your example although it appears you intended base 104.

You have the 3rd entry correct as representing Riesel (-1) or Sierp (+1).

The 4th entry is the highest factor you wish the program to consider. 10e3 or 25e3 is a good starting point. The higher it is, the longer the program runs but if you make it too low, it might not find the lowest conjectured k-value that has a covering set of factors.

The 5th entry is the highest k-value you wish the program to consider as the conjectured k. For a base this high, 1e6 should be sufficient but if it doesn't find anything, try 10e6. You chose '3 5 13' and the program picked it up as '3' hence it did not find a k-value with a full covering set. Riesel base 2 should be k=509203, i.e. the former Riesel Sieve project.

BTW, for Riesel base 104, the conjecture would be k=4 with a covering set of {3 5}, which is easily proven because:
k=1 has a trivial factor of 103 for all n
k=2 has a prime at n=68
k=3 has a prime at n=1

See if you can make the program spit out k=4 as the conjecture for Riesel base 104 and k=509203 as the conjecture for Riesel base 2 by messing around with some of the above parameters. If you get that far, it'll be straightforward for most bases after that.


Gary

Gary,

Thank you very much!
I will try as soon as possible.

Regards
Cedric

[CODE]
72
104
-1
1000000 (10e6)
3 5 13
Checking k*104^n-1 sequence for exponent=72, bound for primes in the covering se
t=1000000, bound for k is 3
Examining primes in the covering set: 3,5,7,67,163,29,373,3571,17,1657,4153,19,1297,2791,18397,37,291853,73
And their orders: 2,2,2,3,3,4,4,6,8,8,8,9,9,9,9,18,36,72[/CODE]

Sorry for the stupid questions, but the "covering set" is this the list of number that I should test or definetly not???

Again sorry ... I am trying and will to understand it.
Regards
C.

[quote=CedricVonck;144877][code]
72
104
-1
1000000 (10e6)
3 5 13
Checking k*104^n-1 sequence for exponent=72, bound for primes in the covering se
t=1000000, bound for k is 3
Examining primes in the covering set: 3,5,7,67,163,29,373,3571,17,1657,4153,19,1297,2791,18397,37,291853,73
And their orders: 2,2,2,3,3,4,4,6,8,8,8,9,9,9,9,18,36,72[/code]

Sorry for the stupid questions, but the "covering set" is this the list of number that I should test or definetly not???

Again sorry ... I am trying and will to understand it.
Regards
C.[/quote]

Your input is not correct. Here is a good example (using the winxp dos console):
[code]
c:\>covering.exe
144 [enter]
121 [enter]
1 [enter]
100000 [enter]
10000000 [enter]

Checking k*121^n+1 sequence for exponent=144, bound for primes in the covering set=100000, bound for k is 10000000
Examining primes in the covering set: 61,7,19,37,7321,13,1117,17,10657,20113,51329,97,241,1777,73,40177,577,3457
And their orders: 2,3,3,3,4,6,6,8,12,12,16,24,24,24,36,36,48,144
**************** Solution found ****************
1300068
**************** Solution found ****************
720586
**************** Solution found ****************
312640
**************** Solution found ****************
4192
**************** Solution found ****************
360
[/code]

- 144 is the "exponent". It is used to calculate the different periods used for the primes considered. You get the best results by picking a number with a lot of small devisors. 144 is a very good one for this. In short, just pick 144 and you'll find a good solution in 99.9% of the cases.
- 121 is the base (b) in k*n^b+/-1
- 1 is the choice between sierpinski or riesel. It can be 1 or -1.
- 100000 is the upper boundary for the primes considered for the covering set. Only primes smaller as this number are considered for the covering set. Incresing this number slows down the covering.exe program significantly.
- 10000000 is the upper boundary of the k considered. If you can't find a solution this is the number you should increse (unless you are looking for a covering set for a k smaller as a current known one).

A covering set is a set of primes which makes all solutions for k*n^b+/-1 composite for a specific k (so no prime can be found).

One more question from me: How do you calculate the number of digits for a nubmer in the form k*n^b+/-1?

digits = integer(log(k)+log(b)*n+1)
for k*base^n+/-1

Now that I have the conjectures linked from here:
[URL]http://mersenneforum.org/showpost.php?p=152196&postcount=176[/URL]
is it just a matter of changing the script that Kep sent me and running WinPFGW?
[code]SCRIPT // autobodgified by scriptify.pl
: pre-declare scriptify's globals
DIMS PCtmpString
OPENFILEAPP noprimesfile,HiCands.rb3
OPENFILEAPP primefile,LoPRPs.rb3
DIM mink,600000002
DIM maxk,610000000
DIM minn,1
DIM maxn,1000
DIM bignum
DIM k
DIM n
SET k,mink
SET n,minn
LABEL label
IF !(k>maxk) THEN GOTO PCnotif_a
GOTO end
LABEL PCnotif_a
SET bignum,k*3^n-1
PRP bignum
IF !(ISPRIME) THEN GOTO PCnotif_b
: synthesise fprintf
SETS PCtmpString,%d*3^%d-1;k;n
WRITE primefile,PCtmpString
SET k,k+(2)
PRINT k
SET n,1
GOTO label
GOTO PCendelse_c
LABEL PCnotif_b
IF !(n<maxn) THEN GOTO PCnotif_d
SET n,n+(1)
GOTO label
GOTO PCendelse_e
LABEL PCnotif_d
: synthesise fprintf
SETS PCtmpString,%d*3^n-1;k
WRITE noprimesfile,PCtmpString
SET n,1
SET k,k+(2)
GOTO label
LABEL PCendelse_e

LABEL PCendelse_c

LABEL end
END[/code]Those GOTOs hurt my brain. :huh: But I can se the variables/constants I would need to change, and possible also the k increment.
Do I assume that if there is no reference to work on a conjecture in this forum (or Gary's stats) that that conjecture is available? (As advised, I would chose a low conjecture.)
If I am correct do you have any recommendations for a nice juicy Reisel that I could start that might be proved in days/weeks?

[quote=Flatlander;152972]Now that I have the conjectures linked from here:
[URL]http://mersenneforum.org/showpost.php?p=152196&postcount=176[/URL]
is it just a matter of changing the script that Kep sent me and running WinPFGW?
[code]SCRIPT // autobodgified by scriptify.pl
: pre-declare scriptify's globals
DIMS PCtmpString
OPENFILEAPP noprimesfile,HiCands.rb3
OPENFILEAPP primefile,LoPRPs.rb3
DIM mink,600000002
DIM maxk,610000000
DIM minn,1
DIM maxn,1000
DIM bignum
DIM k
DIM n
SET k,mink
SET n,minn
LABEL label
IF !(k>maxk) THEN GOTO PCnotif_a
GOTO end
LABEL PCnotif_a
SET bignum,k*3^n-1
PRP bignum
IF !(ISPRIME) THEN GOTO PCnotif_b
: synthesise fprintf
SETS PCtmpString,%d*3^%d-1;k;n
WRITE primefile,PCtmpString
SET k,k+(2)
PRINT k
SET n,1
GOTO label
GOTO PCendelse_c
LABEL PCnotif_b
IF !(n<maxn) THEN GOTO PCnotif_d
SET n,n+(1)
GOTO label
GOTO PCendelse_e
LABEL PCnotif_d
: synthesise fprintf
SETS PCtmpString,%d*3^n-1;k
WRITE noprimesfile,PCtmpString
SET n,1
SET k,k+(2)
GOTO label
LABEL PCendelse_e

LABEL PCendelse_c

LABEL end
END[/code]Those GOTOs hurt my brain. :huh: But I can se the variables/constants I would need to change, and possible also the k increment.
Do I assume that if there is no reference to work on a conjecture in this forum (or Gary's stats) that that conjecture is available? (As advised, I would chose a low conjecture.)
If I am correct do you have any recommendations for a nice juicy Reisel that I could start that might be proved in days/weeks?[/quote]


I'm not familiar with the language used here but it appears that it would only work for base 3. Do you know how to figure k's with trivial factors? As a random example, on Riesel base 67, k's where k==(1 mod 2), k==(1 mod 3), and k==(1 mod 11) would not be considered with factors of 2, 3, and 11 respectively. The above script only eliminates k==(1 mod 2), i.e. odd n, which are the only k's with a trivial factor for base 3.

BTW, in case you haven't noticed, to come up with the k's that have trivial factors, you subtract 1 from the base and take the prime factors of that. It then becomes all k's that are [1 mod (factor)] for all of the prime factors. For example on Riesel base 67:

67-1=66

prime factors of 66 = 2*3*11

Therefore Riesel base 67 has the following k's with trivial factors:
k==(1 mod 2)
k==(1 mod 3)
k==(1 mod 11)

For Sierp base 67, it's the same only the mod is slightly different, i.e.
k==(1 mod 2)
k==(2 mod 3)
k==(10 mod 11)


If you can get the k's with trivial factors down pat and change the above program to account for them, you'll be headed in the right direction.

I won't talk about k's with algebraic factors that make a full covering set right now. :smile: Base 3 doesn't have any that I'm aware of so it was not an issue in this program. Also on bases that are perfect squares, you need to refer to the square root of the base for work that would have effectively already been done. Riesel base 25 is an excellent example of how tricky it can be to avoid double-work on bases that are perfect square. Effectively a ton of work on it had already been done by the base 5 project.

If you still want to tackle a new base after reading this, I can likely give you a couple of good bases to go after that shouldn't take too long to prove. If they aren't perfect squares nor do they have k's with algebraic factors that make a full covering set, it's not bad.


Gary

Okay, obviously more complicated than I thought!
I had noticed the trivial factors mentioned on your site. I had assumed that if I test every k the trivial ks would be illiminated by WinPFGW (with -f) because a factor would be found quickly. Then after testing to n=1000, say, any remaining k would be 'genuine'. If the conjectured k was just a few hundred then very little time would be wasted.
Am I misunderstanding something here?
[B][edit: yes I think I am!]
[edit2: Yes, I know I am! We're looking for primes not factors!]
[/B]
[quote]I won't talk about k's with algebraic factors that make a full covering set right now.[/quote]Probably for the best! I'm still to grasp this 'covering set' stuff.

[quote]BTW, in case you haven't noticed, to come up with the k's that have trivial factors, you subtract 1 from the base and take the prime factors of that...[/quote]I hadn't noticed so I've learned [I]something [/I]today. :smile:

Maybe the best way would be if you choose a base for me and tell me exactly what to do. I know you've just come back from a business trip and have lots to do, so I'll wait patiently. :smile:

Thanks
Chris

the script that was attached in post 3 is the one i use
it is easier to understand IMO

[quote=henryzz;153011]the script that was attached in post 3 is the one i use
it is easier to understand IMO[/quote]
Thanks. I'd missed that one, I'll take a look. :smile:

[quote=Flatlander;152990]Okay, obviously more complicated than I thought!
I had noticed the trivial factors mentioned on your site. I had assumed that if I test every k the trivial ks would be illiminated by WinPFGW (with -f) because a factor would be found quickly. Then after testing to n=1000, say, any remaining k would be 'genuine'. If the conjectured k was just a few hundred then very little time would be wasted.
Am I misunderstanding something here?
[B][edit: yes I think I am!][/B]
[B][edit2: Yes, I know I am! We're looking for primes not factors!][/B]

Probably for the best! I'm still to grasp this 'covering set' stuff.

I hadn't noticed so I've learned [I]something [/I]today. :smile:

Maybe the best way would be if you choose a base for me and tell me exactly what to do. I know you've just come back from a business trip and have lots to do, so I'll wait patiently. :smile:

Thanks
Chris[/quote]


On your "edit2", it looks like you figured it out. If we leave k's with trivial factors in for PFGW to search, it will just keep finding the same factor for them over-and-over for all n-values for those k's. It will never eliminate them. It takes little CPU time but makes for some huge results files and accomplishes nothing since the k's with trivial factors can be easily determined ahead of time. It would be like searching odd-k for base 3. All would remain forever because all have a factor of 2.

OK, I can come up with an easier one for you and simply explain which k's have trivial factors and hence should not be searched. Going to bed now so I'll round up something for you later today.

Unfortunately I've already done most of the very easy Riesel bases < 125. But there should be plenty for Riesel bases 125 thru 200 that will be doable for you. We could do a Sierp base but Prof. Caldwell's group did a lot of work for bases <= 100 on it already. Of course we could do bases > 100 on the Sierp side if you'd like.

Many bases with large conjectures are not any more difficult to start, they just take forever to prove. lol


Gary

[quote=Flatlander;152990]Maybe the best way would be if you choose a base for me and tell me exactly what to do. I know you've just come back from a business trip and have lots to do, so I'll wait patiently. :smile:

Thanks
Chris[/quote]


OK, here is what I have for you from easiest to hardest:

Easy to get your feet wet:
Riesel base 140 with a conjecture of k=46.

The only trivial factors here are k==(1 mod 139), so effectively only k=1 is eliminated. So you can test k=2 thru 45. I'd suggest a PFGW script going up to n=3000. I suspect it will be proven by that point but it may not.


Medium:
Riesel base 154 with a conjecture of k=216.

This has trivial factors where k==(1 mod 3) and (1 mod 17). I suggest 2 PFGW scripts:
(1) One where k==(0 mod 3).
(2) One where k==(2 mod 3).

You can do this by a statement in the script:
(1) b: from 0 thru 215 step 3
(2) b: from 2 thru 215 step 3

Instructions:
1. Run the above scripts up to n=3000 using the -f100 and -l parameters.
2. Look at the end of the results files, i.e. pfgw.out, for the k's that are remaining. You will see that all k==(1 mod 17) will remain. That's because they all have a trivial factor of 17. Those should be removed. What is left over are the TRUE k's that are remaining.
3. Use the true k's remaining from #2 to run PFGW up to n=5000 or 10000. Optionally you can sieve the k's at this point and start using LLR or Phrot.
(That's it.)


Hard:
Riesel base 143 with a conjecture of k=1226.

This has trivial factors where k==(1 mod 2) and (1 mod 71). I would suggest only one script that eliminates all of the odd k's for this one. After running it, then look in the results file and eliminate the k's==(1 mod 71) before continuing on.

If you have any questions about this one, first refer to the process for base 154. If you're still unsure, get back with me.

I cannot guarantee that there are not algebraic factors for some k's on these bases. If you have some stubborn k's that are perfect squares, then that is a good possibility, although still not a probability. Let me know you if you have any k's that are perfect squares remaining. I can step you through the process to check for them.


Gary

Thanks Gary. :smile: I'll check them out.
Primes for n=1 count, yes?

[quote=Flatlander;153220]Thanks Gary. :smile: I'll check them out.
Primes for n=1 count, yes?[/quote]

Yes; n=1 counts. n=0 does not.

[quote=gd_barnes;153141]...
I cannot guarantee that there are not algebraic factors for some k's on these bases. If you have some stubborn k's that are perfect squares, then that is a good possibility, although still not a probability. Let me know you if you have any k's that are perfect squares remaining. I can step you through the process to check for them.
Gary[/quote]

For R base 154 I have just k=9 and k=144 left at n=10k.

[QUOTE=Flatlander;153423]For R base 154 I have just k=9 and k=144 left at n=10k.[/QUOTE]

That means that you have proven the conjecture for base 154: Both 9 and 144 are squares, so for even n = 2m: 9*154^2m-1 = (3*154^m + 1)(3*154^m - 1).
And for the odd n there is always factor 5.

Cheers, Willem.

[quote=Siemelink;153484]That means that you have proven the conjecture for base 154: Both 9 and 144 are squares, so for even n = 2m: 9*154^2m-1 = (3*154^m + 1)(3*154^m - 1).
And for the odd n there is always factor 5.

Cheers, Willem.[/quote]

Okay, thanks. :smile:
I'll start Riesel base 143.

[quote=Flatlander;153423]For R base 154 I have just k=9 and k=144 left at n=10k.[/quote]

[quote=Siemelink;153484]That means that you have proven the conjecture for base 154: Both 9 and 144 are squares, so for even n = 2m: 9*154^2m-1 = (3*154^m + 1)(3*154^m - 1).
And for the odd n there is always factor 5.

Cheers, Willem.[/quote]

[quote=Flatlander;153523]Okay, thanks. :smile:
I'll start Riesel base 143.[/quote]


Very good.

Thanks for helping with the algebraic factors that make a full covering set Willem.

Chris, just post all the primes here and I'll update the web pages to show the base proven. Good job.

Edit: I just looked a little closer at your post. Were k=9 and 144 the ONLY k's remaining at n=10K? If so, then it is proven.


Thanks,
Gary

[quote=gd_barnes;153525]Very good.

Thanks for helping with the algebraic factors that make a full covering set Willem.

Chris, just post all the primes here and I'll update the web pages to show the base proven. Good job.

Edit: I just looked a little closer at your post. Were k=9 and 144 the ONLY k's remaining at n=10K? If so, then it is proven.


Thanks,
Gary[/quote]
Yes, the only ks remaining.

i was thinking about starting a new base,and i found that riesel base 129 has a conjectured smallest riesel k of 14.i though it would be very easy to prove and it would give me an idea of what im doing.so i start with this

[code]SCRIPT
DIM base, 129
DIM min_k, 1
DIM max_k, 13
DIM max_n, 1000

OPENFILEAPP k_file,pl_remain.txt
OPENFILEAPP p_file,pl_prime.txt
DIMS tmpstr
DIM n
DIM k_step, 1
DIM k

IF (base % 2 == 1) THEN SET k_step, 2
IF (base % 2 == 1) && (min_k % 2 == 1) THEN SET min_k, min_k + 1
SET k,min_k - k_step

LABEL next_k
SET k, k + k_step
IF (k > max_k) THEN GOTO END
IF (k % 5 == 1) THEN GOTO next_k
IF (k % 7 == 1) THEN GOTO next_k
SET n, 0

LABEL next_n
SET n, n + 1
PRP k*base^n-1

IF (ISPRIME) THEN GOTO Prime_found
IF (n < max_n) THEN GOTO next_n

SETS tmpstr,%d*%d^n-1;k;base;
WRITE k_file,tmpstr
GOTO next_k

LABEL Prime_found
SETS tmpstr,%d*%d^%d-1;k;base;n;
WRITE p_file,tmpstr
GOTO next_k

END
[/code]

what do i need to change in this script?

[QUOTE=Dougal;196742]i was thinking about starting a new base,and i found that riesel base 129 has a conjectured smallest riesel k of 14.i though it would be very easy to prove and it would give me an idea of what im doing.so i start with this

[code]
IF (k % 5 == 1) THEN GOTO next_k
IF (k % 7 == 1) THEN GOTO next_k
[/code]

what do i need to change in this script?[/QUOTE]

Hi Dougal,

you should delete these two lines. These were there because the previous base. I've attached the same script with full notes, adapted for your base.

Good luck! Willem.

First thing, we factor [B]base-1[/B]; for 129, 128=2^7. But note that 2's are already built into the script. So we remove (or comment out) those lines.

E.g. for R161, 160=2^5*5, again 2's are taken care of, so the line
[FONT=Courier New]IF (k % [B]5[/B] == 1) THEN GOTO next_k[/FONT] is the line to use.
For R88, 87=3*29, then we modify the lines into
[FONT=Courier New]IF (k % [B]3[/B] == 1) THEN GOTO next_k [/FONT]
[FONT=Courier New]IF (k % [B]29[/B] == 1) THEN GOTO next_k[/FONT]
I.e. for every prime factor p of b-1, we use the line
[FONT=Courier New]IF (k % [B]p[/B] == 1) THEN GOTO next_k[/FONT]

For Sierp script, replace -1 things into +1 and the skip conditions should be of form
[FONT=Courier New]IF (k % [B]p[/B] == (p-1)) THEN GOTO next_k[/FONT]
[FONT=Courier New][/FONT]
Did I get this right?

[QUOTE=Batalov;196810]First thing, we factor [B]base-1[/B]; for 129, 128=2^7. But note that 2's are already built into the script. So we remove (or comment out) those lines.

E.g. for R161, 160=2^5*5, again 2's are taken care of, so the line
[FONT=Courier New]IF (k % [B]5[/B] == 1) THEN GOTO next_k[/FONT] is the line to use.
For R88, 87=3*29, then we modify the lines into
[FONT=Courier New]IF (k % [B]3[/B] == 1) THEN GOTO next_k [/FONT]
[FONT=Courier New]IF (k % [B]29[/B] == 1) THEN GOTO next_k[/FONT]
I.e. for every prime factor p of b-1, we use the line
[FONT=Courier New]IF (k % [B]p[/B] == 1) THEN GOTO next_k[/FONT]

For Sierp script, replace -1 things into +1 and the skip conditions should be of form
[FONT=Courier New]IF (k % [B]p[/B] == (p-1)) THEN GOTO next_k[/FONT]
[FONT=Courier New][/FONT]
Did I get this right?[/QUOTE]

For the Riesel part: absolutely correct.
For the Sierpinsky: don't ask me, I don't know first thing about those!

Willem.
PS ok, ok, I'll adapt my script to include Sierpinsky if it so easy.

Well guys the system about trivial factors is the same, no matter if we are talking Riesel or Sierpinski numbers. All primefactors of b-1 (both on the Riesel and Sierpinski bases), tells us which numbers of k has trivial factors. Example given:

Riesel base 128, has b-1=127 (127 is a prime, so no further factors), which means that for all k mod 127 = 1 (128, 255, 383 etc.) there is trivial factors for all n's.

Sierpinski base 128, has b-1=127 (127 is a prime, so no further factors), which means taht for all k mod 127 = 126 (126, 253, 381 etc.) there is trivial factors for all n's.

A final note, on the Riesel side, for some reason that I'm not aware of, k=1 is always excluded from any testings. However this is not the case on the Sierpinski side.

Hope this helped :smile:

Regards

KEP

ok,so i started riesel base 129,i found primes for all k up to the conjectured lowest riesel k (14) apart from k=4.all were k eliminated long before n=1000,but k=4 still stands at n=20000,is there a reason for this,or have i just not found a prime for it yet?

[QUOTE=Dougal;197003]ok,so i started riesel base 129,i found primes for all k up to the conjectured lowest riesel k (14) apart from k=4.all were k eliminated long before n=1000,but k=4 still stands at n=20000,is there a reason for this,or have i just not found a prime for it yet?[/QUOTE]

The reason is that you just havent found a prime for it yet. It will most likely not yield a prime for maybe quite some time, since it is a very low weight k, with <1 % of the initial candidates at sieve depth p=0 remaining at p=1G. So with paitence and a gigantic sieving, maybe of a higher n-value of 10 or 100M, you will maybe eventually find a prime for this base. But remember many bases that has 1 k remaining at n=25K also has 1 k remaining at n=100K or higher :smile: Chances is of course always that you missed the prime, however if your computer can pass a Prime95 torture test, this is most likely not the case :smile:

KEP

thanks for clearing that up.

[QUOTE=Dougal;197003]ok,so i started riesel base 129,i found primes for all k up to the conjectured lowest riesel k (14) apart from k=4.all were k eliminated long before n=1000,but k=4 still stands at n=20000,is there a reason for this,or have i just not found a prime for it yet?[/QUOTE]

You spotted it well, there is a reason for this. The tip off is that k = 4 and 4 is a square.
All entries with an odd exponent have a factor 5.
For all entries with an even exponent n = 2m the following holds:
4*129^2m-1 = 2^2*129^2m-1 = (2*129^m)^2-1 = (2*129^m+1)(2*129^m-1).
So there is always a factor for k = 4.

Willem.

so this base is proven,or not?

[QUOTE=Dougal;197013]so this base is proven,or not?[/QUOTE]

Indeed it is, congratulations.

Willem.

[quote=Dougal;197013]so this base is proven,or not?[/quote]

Hi Dougal,

I know it sounds a little confusing but by (bad) luck, you happened to encounter a base that has a k that contains partial algebraic factors that make a full covering set to eliminate the k.

I know that probably sounds a little confusing but it means that the k is proven composite for all n-values and so is not considered.

If you want to get into the math behind how and why this happens, see [url]http://www.mersenneforum.org/showthread.php?t=11143[/url].


Gary

[quote=KEP;196887]A final note, on the Riesel side, for some reason that I'm not aware of, k=1 is always excluded from any testings. However this is not the case on the Sierpinski side.

Regards

KEP[/quote]

k=1 is considered on both sides but by definition on the Riesel side, all k=1 except base 2 have a trivial factor. See it on the pages. Examples:

Base 2 has no trivial factors so k=1 is considered but is quickly eliminated because 1*2^2-1=3 is prime.

Base 3, k=1 is eliminated with a trivial factor of 2.

Base 4, k=1 is eliminated with a trivial factor of 3.

Base 5, k=1 is eliminated with a trivial factor of 4 (actually 2).

Base 6, k=1 is eliminated with a trivial factor of 5.

(etc.)

On the Sierp side, for even bases, all k=1 make GFN's and so are not considered because many of them most likely will not have a prime, even though we cannot prove it with today's math knowledge. For odd bases, all k=1 are eliminated with a trivial factor of 2.

The effect of all of this is that k=1 only needs a prime for Riesel base 2 but that has already been found so no bases remain where k=1 needs a prime.


Gary

For the rieselator script, I suggest that you use the GCD function to eliminate k. For example, if b = 16, then you need to add the lines

IF (k % 3 == 1) THEN GOTO next_k
IF (k % 5 == 1) THEN GOTO next_k

What you could do is this:

SET km1, k - 1
SET bm1, b - 1
IF (GCD(km1, bm1) > 0) THEN GOTO next_k

That would make the script for any b out of the box. One would just have to modify max_k and max_n.

IIUC, for Sierpinski, these lines would be:

SET kp1, k + 1
SET bm1, b - 1
IF (GCD(kp1, bm1) > 0) THEN GOTO next_k

It should be possible to write a script that works for both Sierpinski and Riesel and have a switch that controls the +1/-1 specific code.

Thoughts?

that looks brilliant rogue

it would also be very helpful if someone could add removing multiplier of base ks properly
edit: if i was completely sure about how it works i would add it myself

[QUOTE=henryzz;197698]that looks brilliant rogue

it would also be very helpful if someone could add removing multiplier of base ks properly
edit: if i was completely sure about how it works i would add it myself[/QUOTE]

I'm done with the script. I have one question for Gary (in another thread) that I need him to answer before I post any scripts. I think that it is important that the script shows a proof explaining why those k can be safely skipped.

read also this [url=http://www.mersenneforum.org/showthread.php?t=10864]thread[/url]:

there're explanations, how the MOBs work and how to implement.

especially posts #40, #43 and #58

Ian (MyDogBuster) has sent me what appears to be a failproof script. I'm in contact with him on how to run it.

His script appears excellent. Not only will it eliminate M'sOB and k's with trivial factors, it will also work for both Riesel and Sierp, AND write out 4 separate files!! The files are:
1. Primes.
2. k's remaining.
3. k's eliminated by trivial factors.
4. k's eliminated that were MOB.

Ian, I think the only "easy" thing left is to have it automatically eliminate k's that make GFN's on the Sierp side. These would be POWERS (not multiples) of the base for even Sierp bases only. As an example, it would be k=6^0, 6^1, 6^2, 6^3, etc., i.e. k=1, 6, 36, 216, etc., for Sierp base 6.

Never fear everyone, pretty soon most new bases will be easy to start.

The only tricky ones will be bases with algebraic factors that can eliminate k's and perfect square (or greater power) bases where primes already found from smaller bases preclude us from having to search them.

Speaking of algebraic factors, it will also be very possible in the future to have a script that removes MOST k's that have algebraic factors (to make a full covering set) for k's that are perfect squares per the "generallizing algebraic factors" thread. We can't do them all at this point because we don't know them all. Some are so esoteric (i.e. very rare perfect cubes) that there's virtually no way to program for them. [See Sierp base 63 with only 2 k's that can be eliminated that are perfect cubes on a conjecture of k>37M for a good example.]


Gary

Gary, The script puts out 4 files, You forgot about the remaining k's file.
As I told you it is highly plagraized so thanks to all who I stole stuff from.
I think it was mainly Willem's scr.txt that I tweaked. I just looked at Scripitfy again and it is possible to code the script so that
you only tell the script whether it's Riesel or Sierp and the script will handle all the sign changes.

I created the extra files so that one could see the whole picture in front of them. I mainly wanted them so that I could insure that ALL k's were tested.

I'll look into doing that powers of the base stuff also.

Funny thing is that I just now realized that and came on to correct it. I'm doing that now.

BTW, it writes out a primes file like this:

[code]
39112687962150934484295053
513134110502509
19565295377
769701165753763
1026268221005017
51358900363
10518791926523
58695886129
13720163382421
21251424727068768200453
95380814959
100272138803
117391772257
24238955308943
158968024931
6902239052144282556052069
12157023826708828069803060538194761886686632539194100390158404160586945545569691991661836167062642848351274130486081632589645849
5901042270778843
[/code]


Do I have a switch set wrong? I'm only using the trial factoring switch -f100. Or do you have a way to convert those into k*b^n+/-1 format?


Gary

Thats the pfgw-prime.txt file, the real one is pl_prime.txt.
PFGW creates the first one as some kind of work file.
I just delete it when I'm done.

[QUOTE=gd_barnes;197898]BTW, it writes out a primes file like this:

[code]
39112687962150934484295053
513134110502509
19565295377
769701165753763
1026268221005017
51358900363
10518791926523
58695886129
13720163382421
21251424727068768200453
95380814959
100272138803
117391772257
24238955308943
158968024931
6902239052144282556052069
12157023826708828069803060538194761886686632539194100390158404160586945545569691991661836167062642848351274130486081632589645849
5901042270778843
[/code]


Do I have a switch set wrong? I'm only using the trial factoring switch -f100. Or do you have a way to convert those into k*b^n+/-1 format?


Gary[/QUOTE]

This is normal. You're looking at pfgw.log, which is created by pfgw.exe. As this is undecipherable there is the file prime_found.txt that lists all the primes and PRP in the format of k*b^n-1.
I once mentioned this to Rogue if a switch could be included in his next PFGW. Our master programmer sets his own priorities so we'll see.

Willem.

More good news on tweaking my script. I CAN control the signs for Riesel or Sierp. It takes some weird code, but it works. I got it to work when writing to the prime file. I just need to code and test the rest. Ian

Fully automated CRUS script
 

I have some great news for CRUS. Being a former legacy programmer myself, I decided to take a look at the recent changes that Ian made to the PFGW script that is used to start new CRUS bases, which he did a good job on. After looking at it, I kind of got the old fever back and went to town with it. :smile:

Announcing: A nearly fully automated script for starting new bases! All you do is put in the base, type (Riesel or Sierp), min k-value, max k-value, and max n-value and it does the rest. The only thing it won't do is algebraic factors.

Features: Besides writing out the usual primes and k's remaining, it automatically calculates and writes out all of the following that do not need to be tested: k's with trivial factors, k's that are GFN's, and k's that are multiples of the base where k-1 (Riesel) or k+1 (Sierp) are composite.

It will write out 5 files:
1. k's that are GFN's.
2. k's that are MOB where k-1 or k+1 are composite.
3. k's with trivial factors.
4. primes
5. k's remaining.

Attached is a script for Sierp base 172. There are comments towards the beginning that show the only 5 variables that need to be changed with each base; all listed right below those comments.

This is now a powerful tool so I'm going to ask that people "take it easy" and don't innundate me too much. :smile: Please reserve all new bases in advance and please only post one new base per person per day.

I have rightfully heard grumblings that people aren't clear on what I'd like to get on new bases. This should help. If you use this script for a new base or to extend the k-range on an existing base (i.e. bases 3/7/15), please send me the following files from the script:

1. pl_prime.txt*
2. pl_remain.txt
3. pl_MOB.txt

*For large conjecutres, feel free to send only primes for n>1000. I can easily run the primes up to n=1000. If you prefer, you can also send only primes for n>500 or n>2500.

I can easily figure out the trivial k's and GFN's so there's no reason to send those files. They are for completness only. In other words, with those files, all k's are accounted for.

As a final clarification on how to run it, give the script an appropriate name such as "sierp-base187.txt", and type in "sierp-base187.txt -f100" in the GUI interface in Windows or "./pfgw sierp-base187.txt -f100" at the command prompt in Linux (without quotes).

Thanks to Micha and Karsten for the original work on the script and to Willem and Ian for a large amount of modifications to it to get the ball rolling towards this nearly fully automated version.

The script was extensively parallel tested by both Ian (~15 bases) and myself (6 bases) under a variety of different conditions including bases small and large, proven and with many k's remaining, 1000's of k's on base 3, from 1 to 4 different sets of trivial factors, etc.

It can handle bases up to 510510 as well as (to the best of my knowledge) k-values and n-values as high as PFGW can handle them or as long as your patience will allow. :smile:

There should no longer be confusion on starting new bases. Have fun! :smile:


Gary

Looks like a great tool. :smile:
I've just got one question:
What's the best way to find the conjectured k for bases not listed on [URL="http://www.noprimeleftbehind.net/crus/"]the CRUS site[/URL]? [URL="http://www.mersenneforum.org/showthread.php?p=134389#post134389"]covering.exe[/URL] and [URL="http://www.mersenneforum.org/showthread.php?p=144918#post144918"]some guesswork[/URL]?

see [url=http://www.mersenneforum.org/showthread.php?t=10910]here[/url]

[quote=kar_bon;198178]see [URL="http://www.mersenneforum.org/showthread.php?t=10910"]here[/URL][/quote]
Ah, great. :smile:

[quote=gd_barnes;198146]This is now a powerful tool so I'm going to ask that people "take it easy" and don't innundate me too much. :smile: Please reserve all new bases in advance and please only post one new base per person per day.
[/quote]
I somehow think that Mini-Geek didnt notice this remark.:smile: He has posted lots already today.:smile:

[quote=henryzz;198195]I somehow think that Mini-Geek didnt notice this remark.:smile: He has posted lots already today.:smile:[/quote]
Indeed I didn't. Sorry. I just skimmed that post, but looking back I think I read everything except that one line. I'll finish the one I'm doing now (a larger conjecture than the rest I've been doing - Riesel 716 conjectured at 238) and then hold off for a while.

[quote=Mini-Geek;198198]Indeed I didn't. Sorry. I'll finish the one I'm doing now (a larger conjecture than the rest I've been doing - Riesel 716 conjectured at 238) and then hold off for a while.[/quote]
You may as well start a base that will take until several hours and then post the results tomorrow.:smile:

Is there a list somewhere of all the conjectured Riesel and Sierp. numbers for bases <1024? I'd like to take a whack at one or two bases with Gary's new script but can't make heads or tails of what I'm reading about running covering.exe to generate conjecture values.

[quote=mdettweiler;198209]Is there a list somewhere of all the conjectured Riesel and Sierp. numbers for bases <1024? I'd like to take a whack at one or two bases with Gary's new script but can't make heads or tails of what I'm reading about running covering.exe to generate conjecture values.[/quote]
That's exactly what Karsten gave the link to when I asked about how to find conjectured k's:
[quote=kar_bon;198178]see [URL="http://www.mersenneforum.org/showthread.php?t=10910"]here[/URL][/quote]

[quote=Mini-Geek;198210]That's exactly what Karsten gave the link to when I asked about how to find conjectured k's:[/quote]
Ah, thanks! That's exactly what I was looking for.

Another quick question. I see that when I run the script, PFGW seems to be receiving the numbers as their full decimal expansions, not in k*b^n+c form. Would this slow down PFGW by causing it to use its generic PRP test routine rather than its specialized ones for k*b^n+c? Also, this can be kind of annoying since it doesn't let me check on progress very easily; is there a way to rectify this?

[QUOTE=mdettweiler;198220]Another quick question. I see that when I run the script, PFGW seems to be receiving the numbers as their full decimal expansions, not in k*b^n+c form. Would this slow down PFGW by causing it to use its generic PRP test routine rather than its specialized ones for k*b^n+c? Also, this can be kind of annoying since it doesn't let me check on progress very easily; is there a way to rectify this?[/QUOTE]

It has been asked. I haven't taken the time to look at PFGW to see if I can add a switch to disable the decimal expansion.

Not too sure about your first point, but a semi-easy and fairly accurate way to know where you're at is to see the number of bits PFGW says it is, (the second number in the status, x in z/x) and take the base b log of 2^x. log_b(2^x) = log_any(2)*x/log_any(b). e.g. a base 716 number that is 21904 bits is n≈log(2)*21904/log(716)≈2310.

Of course, I'd also prefer if it could show the k*b^n+c form instead. :smile:

[quote=rogue;198223]It has been asked. I haven't taken the time to look at PFGW to see if I can add a switch to disable the decimal expansion.[/quote]
I'm kind of confused, though...why does it use decimal expansions with this script, but not otherwise?

Also, am I correct in assuming that in this case it's still using the faster k*b^n+1 PRP routines, despite showing the full decimal expansion?

[QUOTE=gd_barnes;198146]
Announcing: A nearly fully automated script for starting new bases! All you do is put in the base, type (Riesel or Sierp), min k-value, max k-value, and max n-value and it does the rest. The only thing it won't do is algebraic factors.

Gary[/QUOTE]

Well done Gary. This will keep the new bases rolling in. Would you mind changing the introduction a bit? You wrote:
#----------------------------------------------------------------------------------------
# The original scripts were written by Micha (Michaf), Karsten (Kar_bon), and
# Ian (MyDogBuster). More recent modifications were made by yours truly (gd_barnes).
#

I feel left out. Unless I am very mistaken, the script you've modified was partly my work (there is significant code overlap with my Rieselator.txt). I would appreciate to be listed in the dev list as well.

Personally I would leave out the word plagiarizing from the introduction, it suggest that you have been doing something naughty. You've excellently collected all the ideas on the forum and bound them in a easy to use script. That is not naughty at all.

Regards, Willem.

[quote=Siemelink;198257]Well done Gary. This will keep the new bases rolling in. Would you mind changing the introduction a bit? ...
I feel left out.[/quote]
He's already planning on it Willem.[quote=gd_barnes;198250]...
This shouldn't be hard to change the script. I need to add Willem as one of the main contributors in the comments anyway ...[/quote]

[quote=Siemelink;198257]Well done Gary. This will keep the new bases rolling in. Would you mind changing the introduction a bit? You wrote:
#----------------------------------------------------------------------------------------
# The original scripts were written by Micha (Michaf), Karsten (Kar_bon), and
# Ian (MyDogBuster). More recent modifications were made by yours truly (gd_barnes).
#

I feel left out. Unless I am very mistaken, the script you've modified was partly my work (there is significant code overlap with my Rieselator.txt). I would appreciate to be listed in the dev list as well.

Personally I would leave out the word plagiarizing from the introduction, it suggest that you have been doing something naughty. You've excellently collected all the ideas on the forum and bound them in a easy to use script. That is not naughty at all.

Regards, Willem.[/quote]


Yep, I goofed in leaving you out. Sorry about that. No worries. You'll be in there with this next fix. Plagarizing was not my word. I left Ian's term in there and I think he was modifying it more for his personal use instead of a big public release. I suppose it has a bit of a negative connotation so I'll come up with something better.

After looking into the GFN issue, it's not so easy after all. I thought I could play right off of the b-1 factoring routine forgetting that it is calculating b-1 factors instead of b factors. From what I can tell, there's not an easy way to make PFGW give the smallest perfect root of a base. It wasn't particularly easy to get all of the unique prime factors of b-1 either. I think I'm going to have to come up with another factoring routine that will see if each unique prime factor of the base occurs the same # of times -or- if there is only one unique prime factor of the base. If one of those is true, then I multiply the unique factors together -or- use the single unique factor to get the smallest root. In the case of Sierp base 1000, it would be 2^3*5^3. Since 2 and 5 occur the same # of times, 2*5=10 is the smallest perfect root of the base and is used as an "alternate base" to come up with GFNs. I know one thing, there will be a lot of variables needed for this.

Ah, just babbling again as usual. It might be a few days on the GFN fix. After much testing, I feel confident that it will work correctly (sans algebraic factors) for any base that is not an even Sierp base and a perfect power. A good majority of those should work too.


Gary

[QUOTE=rogue;198223]It has been asked. I haven't taken the time to look at PFGW to see if I can add a switch to disable the decimal expansion.[/QUOTE]

I just discovered today that PFGW can do this. You can pass an optional string argument to the PRP command. That string argument would be displayed by PFGW instead of the decimal expansion. For example:

SETS test_str,%d*%d^%d%s1;k;base;n;type_str
PRP k * base ^ n + type, test_str

Updated script for starting new bases.
 

To all,

Attached is an updated script for starting new bases. It includes a correction and an enhancement, as follows:

1. Correct the exclusion of GFN's to include where k is a power of a ROOT of the base instead of only k's that are a power of the base. This allows it to effectively exclude k=1, 2, 4, 8, 16, etc. on Sierp bases 512 and 1024. It also excludes k=10 on Sierp 1000, which Tim found in his testing. I had to move the GFN k's calculation after the trivial k's calculation because k's with a trivial factor are immediately excluded.

2. Add Mark's (rogue's) enhancement to properly display results and primes in k*b^n+/-1 (vs. decimal) format. Thanks Mark! Much better. :smile:

I also changed some variable names for clarity as well as updated the comments to include Willem as one of the original contributors and change the related wording a little bit.

All that is left is to exclude k's with algebraic factors. It's almost an impossible task to exclude all of them but at some point in the future, I may add some enhancements to at least exclude all k's that are perfect squares on Riesel bases that are perfect squares. For both sides, we could also exclude all k's that are a perfect power > 2 on bases that are the same perfect power. (i.e. k=8 on base 27, where b and k are perfect cubes). To complicate things, on the Sierp side, that perfect power cannot be a power of 2, i.e. perfect 4th, 8th, 16th, etc. powers don't count. Then there's also the much more common cases that apply to many Riesel bases such as where b==(4 mod 5) where there are more specific k's with partial algebraic factors that make a full covering set.

Ian or anyone else, if you have time to run a parallel test on this version vs. the prior version of the script on several bases, that would be helpful.

[B]Admin edit: This script works only for Windows/Linux PFGW versions 3.2.3 and prior. 3.2.7 is the latest Windows version. When a build for Linux 3.2.7 is posted, I will work on updates for the script.[/B]


:smile: Gary

[QUOTE=gd_barnes;201120]To all,

Attached is an updated script for starting new bases. It includes a correction and an enhancement, as follows:

1. Correct the exclusion of GFN's to include where k is a power of a ROOT of the base instead of only k's that are a power of the base. This allows it to effectively exclude k=1, 2, 4, 8, 16, etc. on Sierp bases 512 and 1024. It also excludes k=10 on Sierp 1000, which Tim found in his testing. I had to move the GFN k's calculation after the trivial k's calculation because k's with a trivial factor are immediately excluded.

2. Add Mark's (rogue's) enhancement to properly display results and primes in k*b^n+/-1 (vs. decimal) format. Thanks Mark! Much better. :smile:

I also changed some variable names for clarity as well as updated the comments to include Willem as one of the original contributors and change the related wording a little bit.

All that is left is to exclude k's with algebraic factors. It's almost an impossible task to exclude all of them but at some point in the future, I may add some enhancements to at least exclude all k's that are perfect squares on Riesel bases that are perfect squares. For both sides, we could also exclude all k's that are a perfect power > 2 on bases that are the same perfect power. (i.e. k=8 on base 27, where b and k are perfect cubes). To complicate things, on the Sierp side, that perfect power cannot be a power of 2, i.e. perfect 4th, 8th, 16th, etc. powers don't count. Then there's also the much more common cases that apply to many Riesel bases such as where b==(4 mod 5) where there are more specific k's with partial algebraic factors that make a full covering set.

Ian or anyone else, if you have time to run a parallel test on this version vs. the prior version of the script on several bases, that would be helpful.


:smile: Gary[/QUOTE]

Great! Now that PFGW 3.2.7 fixes the bugs from 3.2.5, the script must be further modified to support those changes, namely the use of ISPRIME/ISPRP and the PRP/PRIMEM/PRIMEP functions. PFGW 3.2.7 will not work correctly with this script.

[QUOTE]Ian or anyone else, if you have time to run a parallel test on this version vs. the prior version of the script on several bases, that would be helpful.
[/QUOTE]

I'll wait till the dust settles around here. No sense in having 3 things in testing mode at the same time.

[quote=rogue;201163]Great! Now that PFGW 3.2.7 fixes the bugs from 3.2.5, the script must be further modified to support those changes, namely the use of ISPRIME/ISPRP and the PRP/PRIMEM/PRIMEP functions. PFGW 3.2.7 will not work correctly with this script.[/quote]

Ugh. Now I'm forced to update PFGW on my 20+ cores that run PFGW to be able to run the latest version of the script. What a pain. lol :smile:

Clearly I'll change the MOB routine to run PRIMEM or PRIMEP instead of PRP, although that would only affect bases with large conjectures where PFGW doesn't find k-1 or k+1 to be trivially prime. But in the actual testing of k*b^n+/-1, I'll leave that as PRP, which clearly saves CPU time, and is all that is needed in 99%+ of all tests that are composite or found trivially prime (i.e. quickly proven) by PFGW. Another nice enhancement would be to run PRIMEM or PRIMEP after a PRP is found so that people don't have to prove the pfgw.log (PRPs) file after their testing is complete. Of course that means that the prime will show up in both pfgw.log (PRPs) and pfgw-prime.log (proven primes) but since we now have pl_prime.txt and all of those would be proven primes, the usual PFGW files could just be ignored.

3 questions for you:
1. Are the PRP functions the only areas that MUST be changed as a result of your script changes for 2.4.7?
2. Are there other changes that you would expect that might not have to be done?
3. Are all testing bugs worked out of 2.4.7? I want to make sure that I have the most recent stable version.

To correctly fully test this would require that I find a PRP that is composite, which is not easy. Hopefully a few million k's of base 3 will do it with trial factoring set to 0%, i.e. using the -f0 PFGW switch.

Now, there's another interesting enhancement: Write out a file of composite PRPs. I'll save that for some other time.

Babbling again as usual...


Gary

[QUOTE=gd_barnes;201200]3 questions for you:
1. Are the PRP functions the only areas that MUST be changed as a result of your script changes for 2.4.7?
2. Are there other changes that you would expect that might not have to be done?
3. Are all testing bugs worked out of 2.4.7? I want to make sure that I have the most recent stable version.
[/QUOTE]

1. Yes.
2. I didn't touch any other functions/reserved words other than PRP, ISPRP, ISPRIME, PRIMEM, PRIMEC, and PRIMEP.
3. I am not aware of any bugs, but then again I just released the code today and I can only test so much on my own.

For MOB, PRP will most likely return ISPRIME = 1 since the values are either trivially prime or composite.

For the other test, I recommend using PRP first, then using PRIMEP/PRIMEM for a primality test. Anything that is PRP, but not prime should get kicked out to another file. Those cases need to be investigated by me and George. Doing this will mean that you only need to look at the pl_prime.txt file for primes and ignore the pfgw output files.

As a forewarning, the next version of PFGW will automatically switch to the next larger FFT size if there is a roundoff or sumout error. I've been wanting to do that for a while. So far it seems to work well for PRP testing and GFN, but primality testing is a bit more complex.

Mark or whomever,

For ease of reference, can you provide me with direct links to the most recent Windows and Linux versions of PFGW 3.2.7?

I'll use that for testing script changes per the above.

I'll then change the direct links in the 1st post of the "PFGW 3.2.0 released" thread. My objective is to keep direct links to the most recently released bugfree version of PFGW quickly accessible there.


Thanks,
Gary

Here are the most recent released binaries for Windows and Linux:
Windows 3.2.7: [URL]http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_win_3.2.7_20100107.zip?revision=196[/URL]
Linux 3.2.5: [URL]http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_linux_3.2.5_20091219.zip?revision=184[/URL]
You might need to get Mark to build Linux 3.2.7.
It's easy to get to them from here: [URL]http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/[/URL] (click on the file you want, then use the link on the "(download)" button)

[QUOTE=gd_barnes;201232]Mark or whomever,

For ease of reference, can you provide me with direct links to the most recent Windows and Linux versions of PFGW 3.2.7?

I'll use that for testing script changes per the above.

I'll then change the direct links in the 1st post of the "PFGW 3.2.0 released" thread. My objective is to keep direct links to the most recently released bugfree version of PFGW quickly accessible there.[/QUOTE]

Obviously the links were provided, but I will be removing 3.2.5 and 3.2.6 because they are buggy. I will have a new release ready by Monday for all platforms. 3.2.7 is stable for use. The next release has new features and no bug fixes.

[quote=rogue;201264]Obviously the links were provided, but I will be removing 3.2.5 and 3.2.6 because they are buggy. I will have a new release ready by Monday for all platforms. 3.2.7 is stable for use. The next release has new features and no bug fixes.[/quote]

OK, there is the stable bugfree version 3.2.7 for Windows. I'll use that to test changes that I will make to the script. But for posting links in the 1st post here, I need stable and known tested bugfree versions for both Windows and Linux. For that reason, would it be too much trouble for you to build version 3.2.7 for Linux?

When the new features versions are posted, I don't feel confident considering them stable and bugfree until a number of people test them because there are usually small bugs in any new features (i.e. versions 3.2.5/3.2.6), either in the new features or in how they affect/interact with previously existing code. So even when those come out, I'll still want to leave Windows and Linux version 3.2.7 as links in the 1st post for a period of time.

One more question: Will there be any fixes or enhancements of the PFGW scripting language in the near future? I want to get that to a stable state before making the final changes to the new bases script for the PRP/PRIME/ISPRP/ISPRIME code.


Thanks,
Gary

[QUOTE=gd_barnes;201335]OK, there is the stable bugfree version 3.2.7 for Windows. I'll use that to test changes that I will make to the script. But for posting links in the 1st post here, I need stable and known tested bugfree versions for both Windows and Linux. For that reason, would it be too much trouble for you to build version 3.2.7 for Linux?[/quote]

Steven Harvey makes the Linux builds. I'll ask him.

[QUOTE=gd_barnes;201335]One more question: Will there be any fixes or enhancements of the PFGW scripting language in the near future? I want to get that to a stable state before making the final changes to the new bases script for the PRP/PRIME/ISPRP/ISPRIME code.[/QUOTE]

There are no changes to the how PFGW handles scripts. In fact, the changes for the next release will address things that scripts could not handle before. For example, if a test failed due to a sumout/roundoff error, you could not use a PFGW script to rerun the test with -a1. With the next release users are always guaranteed a successful test (barring bugs in PFGW or gwnum).

I have run a number of bases through 3.2.7 with an updated script and it is working as documented. These same tests failed with 3.2.6. I have found no issues. I haven't had time to test base with 3.3.0. One of the bases I tested with 3.2.7 had hundreds of sumout/roundoff errors for n < 200. I hope to run some tests today or tomorrow and post the next release once I can verify that it works correctly with those bases.

OK, thanks. I think what I'll do is update the 1st post here with Windows version 3.2.7 and edit my recent script post to tell people that the script only works for PFGW versions 3.2.4 and older.

This is kind of an unusual place to be in. My script changes to correct the GFNs and to incorporate your k*b^n+/-1 displaying is valid for the most recent Linux version 3.2.4 but invalid for Windows version 3.2.7. (I'm not counting 3.2.5/3.2.6 since you said they had bugs.)

I have 10 Linux machines and 2 Windows machines and I'd like to keep them in sync so I'll wait until we have Linux PFGW 3.2.7 before I start working on the newest script changes.

One more question for you: What is the latest bugfree Linux version of PFGW? I'm assuming it's 3.2.4, although I can't find it anywhere. If so, can you provide a direct link? The latest that I have is 3.2.3 and is what is posted in the "PFGW 3.2.0 released" thread. Thanks.


Gary

[QUOTE=gd_barnes;201387]This is kind of an unusual place to be in. My script changes to correct the GFNs and to incorporate your k*b^n+/-1 displaying is valid for the most recent Linux version 3.2.4 but invalid for Windows version 3.2.7. (I'm not counting 3.2.5/3.2.6 since you said they had bugs.)

One more question for you: What is the latest bugfree Linux version of PFGW? I'm assuming it's 3.2.4, although I can't find it anywhere. If so, can you provide a direct link? The latest that I have is 3.2.3 and is what is posted in the "PFGW 3.2.0 released" thread. Thanks.[/QUOTE]

Can you explain by what you mean as "invalid for Windows"? If there is a bug, I will fix it before the next release. Note that for 3.2.7 you would have "PRP test_str" instead of "PRP k * base ^ n + type, test_str". If you are saying the the latter doesn't display correctly in Windows, then what is it displaying?

I thought I had posted a 3.2.4 Linux version, but apparently I didn't. The only difference between 3.2.3 and 3.2.4 is to fix an issue with PRP testing numbers of the form b^n+1. It works, but is slower because it doesn't use the faster modular reduction.

[quote=rogue;201389]Can you explain by what you mean as "invalid for Windows"? If there is a bug, I will fix it before the next release. Note that for 3.2.7 you would have "PRP test_str" instead of "PRP k * base ^ n + type, test_str". If you are saying the the latter doesn't display correctly in Windows, then what is it displaying?

I thought I had posted a 3.2.4 Linux version, but apparently I didn't. The only difference between 3.2.3 and 3.2.4 is to fix an issue with PRP testing numbers of the form b^n+1. It works, but is slower because it doesn't use the faster modular reduction.[/quote]

I said my SCRIPT is invalid for the latest PFGW 3.2.7. I said nothing about PFGW. Everyone says 3.2.7 is good so I assume it is. I haven't upgraded since 3.2.3 because there is not a Linux version later than that that I am aware of.

The bottom line is that I don't want to update my script for your script language changes in Windows PFGW 3.2.7 until we get the latest Linux version of PFGW. The script is great and is bugree after extensvie testing on PFGW 3.2.3; both for Linux and Windows versions.

[QUOTE=gd_barnes;201538]I said my SCRIPT is invalid for the latest PFGW 3.2.7. I said nothing about PFGW. Everyone says 3.2.7 is good so I assume it is. I haven't upgraded since 3.2.3 because there is not a Linux version later than that that I am aware of.

The bottom line is that I don't want to update my script for your script language changes in Windows PFGW 3.2.7 until we get the latest Linux version of PFGW. The script is great and is bugree after extensvie testing on PFGW 3.2.3; both for Linux and Windows versions.[/QUOTE]

I couldn't distinguish if the script was buggy or WinPFGW was buggy from your post.

Steven Harvey is at work on a Linux build of PFGW. I hope to have it available within an hour or two.

I've now added a link to the latest version of the starting new bases script to the 1st post in this thread. Instead of continuing to post them as attachments in this thread, it will be better to have them quickly available in the 1st post. I'll remove the requirement of PFGW 3.2.3 and earlier after the Linux version of PFGW 3.2.7 is available and I have updated it to include the necessary changes.

I have now modified the starting bases script to work with PFGW versions 3.2.7 and later. The 1st post in this thread has been changed to include both versions. 3 major enhancements have been made to the 3.2.7 version:

1. It will automatically primality test unproven PRPs. You never again have to prove the pfgw.log file. :smile:

2. It will write out composite PRPs to file pl_compPRP.txt. This will sometimes be an interesting list for some of the small bases with huge conjectures.

3. It will no longer write empty files. I personally found irritating the frequently empty GFN, k's remaining, MOB, and trivial factors files that needed to be deleted. No more. If the file doesn't exist at the end of your run, it means there were no k's that were applicable for it.


Note that these changes were not made and the first 2 not even possible with the 3.2.3 version.

I only had time to parallel test 3-4 bases although I did attempt to hit all areas of code that were changed. I did find a few old composite PRPs that I was able to get it to write out for base 3. If anyone can run some more parallel tests on it, I'd appreciate it.

Have fun! :smile:


Gary

[quote=gd_barnes;202573]I only had time to parallel test 3-4 bases although I did attempt to hit all areas of code that were changed. I did find a few old composite PRPs that I was able to get it to write out for base 3. If anyone can run some more parallel tests on it, I'd appreciate it.[/quote]
Did you check these "composite PRPs" with -a1 (or higher) to check if it was really the prime proof that was off, and not the PRP?

In my tests on Riesel base 3, I noticed that using PFGW 3.3.1 and the new script made for it makes the memory usage keep growing roughly linearly throughout the run. It's currently at about 400 MB memory usage at about 4/5th through it, so I'd estimate it at 200 MB per million k, (remember that odd k's are eliminated for this work due to trivial factors, so a 4M k range is 2M k's) or about 210 bytes per k (for Riesel base 3 k=805M-810M, n<=1000). I'm not sure what's causing this memory usage. This doesn't occur with the older script and PFGW version, so it must've been introduced somehow in one of those two. Is is storing some information from every k in memory or something?

[QUOTE=Mini-Geek;202622]In my tests on Riesel base 3, I noticed that using PFGW 3.3.1 and the new script made for it makes the memory usage keep growing roughly linearly throughout the run. It's currently at about 400 MB memory usage at about 4/5th through it, so I'd estimate it at 200 MB per million k, (remember that odd k's are eliminated for this work due to trivial factors, so a 4M k range is 2M k's) or about 210 bytes per k (for Riesel base 3 k=805M-810M, n<=1000). I'm not sure what's causing this memory usage. This doesn't occur with the older script and PFGW version, so it must've been introduced somehow in one of those two. Is is storing some information from every k in memory or something?[/QUOTE]

I have an idea as to what could be causing the memory leak. I'll investigate, but I'm not too concerned, since it is likely related to the size of the input. Few users will run millions of k through PFGW at one time.

The output of the old and new setups match, (Riesel base 3 k=805M-810M) ignoring the differences caused by the compPRP removals. These primes all silently fail and return composite with the newest setup: (this is, coincidentally(?), the entire compPRP file)
[code]806928292*3^55-1
808640228*3^54-1
808846184*3^48-1
808953748*3^490-1
809396984*3^49-1
809629928*3^49-1
809696008*3^734-1
[/code]The only apparent problems I see are minor issues with PFGW that I've already reported (a memory leak, posted earlier, and the silently failing primes posted here). The script seems to be working great.

[quote=rogue;202627]I have an idea as to what could be causing the memory leak. I'll investigate, but I'm not too concerned, since it is likely related to the size of the input. Few users will run millions of k through PFGW at one time.[/quote]


It's more common than you might think. Mainly our Riesel and Sierp base 3 efforts but also base 7 and 15 in the future is a big reason that the script comes in handy.

Therefore I'm concerned about it. I recently got a PM from Lennart that he is interested in doing some testing on Sierp base 3. With his resources, he's liable to really test this kind of issue.


Gary

[QUOTE=gd_barnes;202655]It's more common than you might think. Mainly our Riesel and Sierp base 3 efforts but also base 7 and 15 in the future is a big reason that the script comes in handy.

Therefore I'm concerned about it. I recently got a PM from Lennart that he is interested in doing some testing on Sierp base 3. With his resources, he's liable to really test this kind of issue.[/QUOTE]

On this project, yes, but not on other projects.

[quote=rogue;202692]On this project, yes, but not on other projects.[/quote]

Didn't you introduce this problem in the last couple of versions of PFGW as a result of correcting other problems? If so, it shouldn't matter how many projects are impacted. It needs to be fixed.

I lost 4 days processing on a full quad while out of town for 7 days as a result of the memory leak that never existed on previous versions of PFGW. To say I was miffed is an understatement. It makes me want to stick with 3.2.3 and prior. I can code around it by running batch files with smaller ranges but that shouldn't be necessary.

I suspect this may be why Lennart hasn't worked or has worked very little on his k=810M-820M range for Riesel base 3 that he reserved.

If you have an idea of what is causing it, please look into it. Thank you.