Starting new bases

[mdettweiler]

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?

[rogue]

Originally Posted by mdettweiler

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?

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.

[Mini-Geek]

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.

[mdettweiler]

Originally Posted by rogue

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.

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?

[Siemelink]

Originally Posted by gd_barnes

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

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.

[Mini-Geek]

Originally Posted by Siemelink

Well done Gary. This will keep the new bases rolling in. Would you mind changing the introduction a bit? ...
I feel left out.

He's already planning on it Willem.

Originally Posted by gd_barnes

...
This shouldn't be hard to change the script. I need to add Willem as one of the main contributors in the comments anyway ...

[gd_barnes]

Originally Posted by Siemelink

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.

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

[rogue]

Originally Posted by rogue

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.

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

[gd_barnes]

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.

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.

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.


Gary

[rogue]

Originally Posted by gd_barnes

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.

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.


Gary

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.

[MyDogBuster]

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.

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