Carol / Kynea Primes

[kar_bon]

CK238 tested to n=10k
Primes:

(-1) 1, 2, 7, 68, 2345, 4783, 5425
(+1) 1, 5, 114, 137, 213, 270, 5796, 6798

[Dylan14]

Base 500 has been searched to n = 10k. The following primes were found:

 (500^4+1)^2-2
 (500^5+1)^2-2
 (500^11+1)^2-2
 (500^981-1)^2-2
 (500^2195+1)^2-2

One suggestion: there are sieve files for bases 18 and 50 in the reservation thread (posts 45 and 95). I was thinking that these should be posted on the status page, a la CRUS, for easy access.

[gd_barnes]

Originally Posted by Dylan14

Base 500 has been searched to n = 10k. The following primes were found:

 (500^4+1)^2-2
 (500^5+1)^2-2
 (500^11+1)^2-2
 (500^981-1)^2-2
 (500^2195+1)^2-2

One suggestion: there are sieve files for bases 18 and 50 in the reservation thread (posts 45 and 95). I was thinking that these should be posted on the status page, a la CRUS, for easy access.

That certainly makes sense.

I am in the process of requesting admin access from Mark for things of this nature. Once I have that access I will edit the first post of the reservations thread in this forum to show the applicable sieve files. If you know of any others besides those two posts let me know.

At this point I would rather not add a column to the status web page for such things. If at some point the project becomes much bigger with a lot of sieve files available then I feel like we could add a column.

[kar_bon]

Admins work ist hard and timeconsuming, especially if you have to check results. So I understand not to show the "power of" bases with their values like in the tables of Wikipedia:
Every new find in for example base 2 you have to update base 4, 8, 16, 32, 64, ...

So I've invested some time to upgrade my scripts to do this automatically.

New:
- all values from "power of" bases will generated from the 'ground base'
- search limits without delimiter "," in data-file (because calculating the correct limit for "power of" base)
- condensed data ASCII-file contains date of creation now
- for "power of" bases the "ground base" is shown under "base" in brackets
- search limit for "power of" bases calculated from "ground base" limit

Example:
Data file contains:

#32#
power of 2

In general 6 lines per base but here only 2 needed (others empty),

The generated table for the HTML-page looks like this:

32   150000  (-1) 2, 3, 5, 11, 35, 63, 87, 37116, 130698
(2)          --------------------------------------------------------------------------------
             (+1) 1, 3, 13, 36, 111, 136, 160, 214, 330, 1273, 7407, 20487, 21276, 22123, 75210

The condensed data file contains:

  32   150000 (-1) 2, 3, 5, 11, 35, 63, 87, 37116, 130698
              (+1) 1, 3, 13, 36, 111, 136, 160, 214, 330, 1273, 7407, 20487, 21276, 22123, 75210

I've included base 484 and 512 in the data file, too.

So now there's no reason not to show the values for the "power of" bases, too.

Inserting columns for sieve files later can be done also easy here with such script.
Idea: a marker if a sieve file exists and the base number can be turned into a link with the destination of the file.

[LaurV]

Originally Posted by gd_barnes

So if you have a base that you have tested to n=12K, yes please report its results.

I let it run, so it tested base 2018 up to n=27k. I was looking for some higher hit, but no luck. The only output of pfgw for this range (3-PRP test):
(2018^2+1)^2-2
(2018^1800-1)^2-2
(2018^3143+1)^2-2
(2018^3720-1)^2-2
All the others below n=27k (and a bit higher) are for sure composite.
Releasing the base. (do you need the factors file and/or residues? I kept all factors over 1G and all residues over n=10k)

[gd_barnes]

Originally Posted by kar_bon

Admins work ist hard and timeconsuming, especially if you have to check results. So I understand not to show the "power of" bases with their values like in the tables of Wikipedia:
Every new find in for example base 2 you have to update base 4, 8, 16, 32, 64, ...

So I've invested some time to upgrade my scripts to do this automatically.

New:
- all values from "power of" bases will generated from the 'ground base'
- search limits without delimiter "," in data-file (because calculating the correct limit for "power of" base)
- condensed data ASCII-file contains date of creation now
- for "power of" bases the "ground base" is shown under "base" in brackets
- search limit for "power of" bases calculated from "ground base" limit

Example:
<snip>

Karsten, we are not going to agree to this so please stop! We have already been around and around about this by PM. Yes there are TWO very clear reasons not to show these:
1. The data is simply redundant. The same primes are listed multiple times.
2. What if someone wants to reserve base 256? How do we show that reservation for base 2 or 4 or 8 etc? That only n==(0 mod 8) or (0 mod 4) or (0 mod 2) etc. are being tested? Then there are gaps in the testing ranges, which is overly complex. What if they reserve base 128? How do we show that reservation for base 32? That only n==(5 mod 7) are being tested? It would quickly become ridiculous.

#2 is probably the big reason that Mark concluded the same thing. It creates problems because only part of the root bases are being tested. I am trying to maintain the spirit of the project in that regard. CRUS must list the same primes in different bases (which is a hassle but necessary) because the conjectures are different for power bases but that is not applicable here. If the OEIS or WIKI want to show redundant primes/sequences then that is their business. But we will not do it here.

Please respect our wishes and quit pushing this issue. Thank you.

[gd_barnes]

Originally Posted by LaurV

I let it run, so it tested base 2018 up to n=27k. I was looking for some higher hit, but no luck. The only output of pfgw for this range (3-PRP test):
(2018^2+1)^2-2
(2018^1800-1)^2-2
(2018^3143+1)^2-2
(2018^3720-1)^2-2
All the others below n=27k (and a bit higher) are for sure composite.
Releasing the base. (do you need the factors file and/or residues? I kept all factors over 1G and all residues over n=10k)

No that is all. Yes it is quite common for these bases to have large primeless gaps, especially the large bases. Bases 34 and 46 that I recently searched to n=30K were primeless for nearly as much as base 2018.

Thanks for the info.

[gd_barnes]

I have added links to Wikipedia about these searches/primes in the first post of this thread. If you find a prime for a base <= 50 you can feel free to edit the Wiki to add the prime. If you don't care to I will add it.

[kar_bon]

Originally Posted by gd_barnes

Karsten, we are not going to agree to this so please stop! We have already been around and around about this by PM. Yes there are TWO very clear reasons not to show these:
1. The data is simply redundant. The same primes are listed multiple times.
2. What if someone wants to reserve base 256? How do we show that reservation for base 2 or 4 or 8 etc? That only n==(0 mod 8) or (0 mod 4) or (0 mod 2) etc. are being tested? Then there are gaps in the testing ranges, which is overly complex. What if they reserve base 128? How do we show that reservation for base 32? That only n==(5 mod 7) are being tested? It would quickly become ridiculous.

#2 is probably the big reason that Mark concluded the same thing. It creates problems because only part of the root bases are being tested. I am trying to maintain the spirit of the project in that regard. CRUS must list the same primes in different bases (which is a hassle but necessary) because the conjectures are different for power bases but that is not applicable here. If the OEIS or WIKI want to show redundant primes/sequences then that is their business. But we will not do it here.

Please respect our wishes and quit pushing this issue. Thank you.

First (because the post from sweety439 was deleted here):
To get the precise values edit line 55 in the awk-script from "limit=lim[power_of]/cnt" to "limit=int(lim[power_of]/cnt)".

To Gary:

Reason 1:
I agree, that (2^185580-1)^2-2 and (32^37116-^)^2-2 are identical, but the values of n for primes for base 32 and base 2 are different:
only the n-values == (0 mod 5) from base 2 are n-values (divided by 5) for base 32, so they are not the same!

Reason 2:
You contradict yourself! On your page there's the term "Reservations will not be accepted for them." (meant are the power-of bases)
and all power-of bases are marked. So if you satisfy your own restriction, there's no problem with testing gaps.
Your reason 2 is senseless here.

On the other hand: If someone is not aware of your page but is searching for base 32 and find a prime at n~150k (this will be a Top5000 entry worth),
you'll not accept this find because you got no reservation for base 32 (which you will not accept) nor base 2?
Nor you'll not show this find because you got gaps in the search limits? Think about this again.

I've never suggested to search the power-of bases but reduce the work for admins to show the n-values for those bases, too.
Now there's no extra byte to edit in power-of bases for a new find in base 2 or 6 but for all higher bases a new entry will be done automatically if needed.

[rogue]

Originally Posted by kar_bon

First (because the post from sweety439 was deleted here):
To get the precise values edit line 55 in the awk-script from "limit=lim[power_of]/cnt" to "limit=int(lim[power_of]/cnt)".

To Gary:

Reason 1:
I agree, that (2^185580-1)^2-2 and (32^37116-^)^2-2 are identical, but the values of n for primes for base 32 and base 2 are different:
only the n-values == (0 mod 5) from base 2 are n-values (divided by 5) for base 32, so they are not the same!

Reason 2:
You contradict yourself! On your page there's the term "Reservations will not be accepted for them." (meant are the power-of bases)
and all power-of bases are marked. So if you satisfy your own restriction, there's no problem with testing gaps.
Your reason 2 is senseless here.

On the other hand: If someone is not aware of your page but is searching for base 32 and find a prime at n~150k (this will be a Top5000 entry worth),
you'll not accept this find because you got no reservation for base 32 (which you will not accept) nor base 2?
Nor you'll not show this find because you got gaps in the search limits? Think about this again.

I've never suggested to search the power-of bases but reduce the work for admins to show the n-values for those bases, too.
Now there's no extra byte to edit in power-of bases for a new find in base 2 or 6 but for all higher bases a new entry will be done automatically if needed.

One of my reasons for the original restriction is to reduce rework. Let's say that someone tests base 4 to 5e5. We cannot say that base 2 is tested to 10e5, but if someone decides to test base 2 they must now go thru the extra effort of removing terms from base 2 that were already tested with base 4.

Is there any real value to show all base 2 primes as base 4 primes?

If someone is searching for this form, but is not aware of this project, then that would be unfortunate, but there is no way for us to know what n they tested and how they decided which n to test for any base. If they used cksieve,then they are clearly aware of this project and finding primes for any bases would be akin to poaching.

[gd_barnes]

Originally Posted by kar_bon

Reason 2:
You contradict yourself! On your page there's the term "Reservations will not be accepted for them." (meant are the power-of bases)
and all power-of bases are marked. So if you satisfy your own restriction, there's no problem with testing gaps.
Your reason 2 is senseless here.

I think Mark put our reasoning the best that it can be put.

As for your reason 2: We attempt to avoid gaps for the n-values in k's searched at CRUS and even the folks at RPS attempt to avoid them as best they can. But both projects could potentially have gaps in k-values searched. They come up at both CRUS (see S3 right now) and RPS. In the spirit of RPS, it encourages people to search whatever k-values they want and discourages people from leaving gaps in n-values for specific k's, especially at top-5000 range.

To apply that logic to this project, the bases here are logically similar to the k-values at the above 2 projects. We do not ask that people search the bases contiguously. They are free to search whatever base they want just like the k-values at RPS and to a lesser extent at CRUS. But we strongly discourage people from leaving gaps in n-ranges for specific bases.

So as for me contradicting myself. Per the above reasoning; not at all. The power bases that we don't take reservations are not "gaps" or "holes" in the bases. They've already been searched by the root bases. We just choose not to show them on the pages so as to not encourage searches on them. To allow reservations on the power bases leaves n-value holes in the root bases.

People are welcome to do as they please. RPS had the problem for quite a while with a big searcher searching much higher n-ranges than their current search depth for small k's such as k=5. Could we have the problem with someone deciding to, say, search base 4 for n=500K-1M? Sure. But like Mark said they would have to use cksieve to do so and they would effectively be poaching our project.