[QUOTE=Citrix;350810]I will put this in the next release and provide more choices for base etc.[/QUOTE]

Citrix,

To be clear, it appears that the starting bases script is quite a bit more complex than you realize. Have you looked at the existing starting bases script? Even for relatively simple base 3, you can't just tell it to test the even k's for a given k-range to a specific n-value. As KEP says, you need to account for k's that are a multiple of the base (MOB) where k-1 is not prime (Riesel) or k+1 is not prime (Sierp). Such k's should not be tested and need to be written to a separate file.

Also, please get your base 3 script working with MOBs, etc. before attempting to generalize it across all bases. In other words, no enhancements before bug fixes. If you are going to generalize it, it becomes quite a bit more difficult. You need to account for entire sets of k's with trivial factors as well as for k's that are GFNs (Generalized Fermat numbers).

Please everyone, this is a beta test version. Do not use it for new ranges. I will not accept the results of them. It should be parallel tested using ranges already tested with the existing new bases script. In case that's not clear, this new script needs to be run and then the old script needs to be run across the same range of k and n-value across a variety of conditions. The output files need to match up perfectly.

This project must be very exacting to avoid missing primes and causing additional testing.


Gary

[QUOTE=gd_barnes;350832]Citrix,

To be clear, it appears that the starting bases script is quite a bit more complex than you realize. Have you looked at the existing starting bases script? Even for relatively simple base 3, you can't just tell it to test the even k's for a given k-range to a specific n-value. As KEP says, you need to account for k's that are a multiple of the base (MOB) where k-1 is not prime (Riesel) or k+1 is not prime (Sierp). Such k's should not be tested and need to be written to a separate file.

Also, please get your base 3 script working with MOBs, etc. before attempting to generalize it across all bases. In other words, no enhancements before bug fixes. If you are going to generalize it, it becomes quite a bit more difficult. You need to account for entire sets of k's with trivial factors as well as for k's that are GFNs (Generalized Fermat numbers).

Please everyone, this is a beta test version. Do not use it for new ranges. I will not accept the results of them. It should be parallel tested using ranges already tested with the existing new bases script. In case that's not clear, this new script needs to be run and then the old script needs to be run across the same range of k and n-value across a variety of conditions. The output files need to match up perfectly.

This project must be very exacting to avoid missing primes and causing additional testing.


Gary[/QUOTE]

I agree with Gary, this should be beta tested first.
I have implemented the MOB. Numbers k =0 (mod base) are eliminated.

GFN are eliminated.
Is there anything else that is needed?

Algebraic factors are too complicated to code for.
:smile:

Slightly faster version attached. :smile:
Has anyone had any errors so far?

Thx.

I'd like to take R3 a bit above k=12G. Should I use the usual starting bases script or is it safe to use Citrix' more speedy code? Nobody submitted any errors for quite some time but I don't know how much testing has been done.

[QUOTE=Puzzle-Peter;356116]I'd like to take R3 a bit above k=12G. Should I use the usual starting bases script or is it safe to use Citrix' more speedy code? Nobody submitted any errors for quite some time but I don't know how much testing has been done.[/QUOTE]

It needs to be parallel tested first. My suggestion: Run both his new script and the old script for a smallish range (maybe k=10M to n=10K) in different directories. Then compare all output files including pl_prime, pl_MOB, and pl_remain. If all files are the same, then it's OK to use his new script for a big range.

OK, I tested k=12,000,000,001 to 12,010,000,000

I misread what Citrix' code says. It says "up to 2500 bits." I mistakenly put max_n=2000 in the newbases script.

So I figured PFGW should find more primes and therefore the candidates left after the run should be less. Plus all the remaining k values from PFGW should be in the left.txt file from Citrix' code. This is mostly the case, but not always. PFGW puts k=12000030864 in pl_remaining.txt but it is not included in left.txt

As 12000030864 is a multiple of 3, it seems the MOB handling needs some tweaking.

Some observations:
- would it be possible to have a user-defined max_n rather than 2500 bits? It would be much easier to compare the results files.
- the code is blazing fast for small n, but seems to take much longer than PFGW when going into higher n values. I started both in parallel and it quickly sprinted ahead of PFGW, but always seemed to wait a long time before writing the k to left.txt and going on. It was still faster in the end (9.5h vs. 10.75h) but it felt like wasting a lot of its potential speed advantage.

This was done on WinXP 32 bit.

[QUOTE=Citrix;350850]Algebraic factors are too complicated to code for.[/QUOTE]

The gain for such small n would be minimal compared to the amount of coding needed.

[QUOTE=Puzzle-Peter;356306]OK, I tested k=12,000,000,001 to 12,010,000,000

I misread what Citrix' code says. It says "up to 2500 bits." I mistakenly put max_n=2000 in the newbases script.

So I figured PFGW should find more primes and therefore the candidates left after the run should be less. Plus all the remaining k values from PFGW should be in the left.txt file from Citrix' code. This is mostly the case, but not always. PFGW puts k=12000030864 in pl_remaining.txt but it is not included in left.txt

As 12000030864 is a multiple of 3, it seems the MOB handling needs some tweaking.
[/QUOTE]

This is why we have to parallel test. Assuming that k=12000030864 has no primes up to n=2000, it [I]should [/I]be in pl_remaining as done by PFGW (left.txt in Citrix' code) because 12000030864 - 1 = 12000030863 is prime. If 12000030863 was composite, then 12000030864 would need to be in pl_MOB. So like you said, it looks like Citrix' code need some tweaking.

I'm a little confused by "2500 bits". Wouldn't that be n=2500 base 2 ? There is no equivalent exact n-value base 3. Maybe you're saying that his script is testing to n=2500 base 3. Regardless, we have to have an exact parallel test so you'd need to redo the PFGW run. [I]All[/I] files must match exactly. This is a very exacting project.

It appears that Citrix' script is not ready for prime time yet.

[QUOTE=Citrix;350850]I agree with Gary, this should be beta tested first.
I have implemented the MOB. Numbers k =0 (mod base) are eliminated.

GFN are eliminated.
Is there anything else that is needed?

Algebraic factors are too complicated to code for.
:smile:[/QUOTE]

You can't just eliminate [I]all[/I] k's where k is a multiple of the base. You should only eliminate k's (that is write the k to a MOB file) where [I]both[/I] of the following conditions are true:
1. k is a multiple of the base
2. k - 1 is composite (Riesel) or k + 1 is composite (Sierp).

Are separate files written for MOB and GFN ? All k's have to be accounted for.

Please re-review the CRUS starting bases script. Thanks.

[QUOTE=gd_barnes;356317]I'm a little confused by "2500 bits". Wouldn't that be n=2500 base 2 ? There is no equivalent exact n-value base 3. Maybe you're saying that his script is testing to n=2500 base 3. Regardless, we have to have an exact parallel test so you'd need to redo the PFGW run. [I]All[/I] files must match exactly. This is a very exacting project.
[/QUOTE]

When you start it, it says it's testing numbers "less than 2500 bits". When I realized my misreading "2500 bits" vs. "max_n = 2000" the test was running already. I tried to evaluate an n to get exactly 2500 bits using base 3 only to find there is no n value to get an exact equivalent. That's why I suggested having the user enter the maximum n value so the test range is exactly the same as defined in the PFGW script.

2500 bits is 2^2500 and not 3^2500. The code above is faster than PFGW for small n but for large n it becomes extremely slow. I included the 2500 bits as the default range since anything larger will make the program too slow and anything smaller will increase the work too much. I can change this to custom n range for the next release.

2500 bits for base 3 will be n=2500*log(2)/log(3)=1577.324