Aliquot sequences that start on the integer powers n^i

[EdH]

Here is a list of all 12 digit primes that appear in more than one sequence (excluding merges) throughout the entire set of tables (as far as I can tell):

109964639887,193,22,263
109964639887,40,19,182
126249927637,15472,5,113
126249927637,67,75,5
142754777149,101,32,504
142754777149,52,39,640
154198251007,17,76,702
154198251007,22,87,1336
194041181491,439,22,392
194041181491,76,35,2974
220689850709,12496,19,494
220689850709,15,12,3377
389689791443,10,109,4650
389689791443,15,34,1318
392293758937,10,85,807
392293758937,42,23,2984

Some manual editing was done. I hope I didn't introduce any errors this time.

[garambois]

Originally Posted by EdH

I think it all looks good, except for a minor point. If it is important, the other thread is only for reserving smaller (<145 digit) matched parity (and doubled square) sequences. Perhaps, "term <145 digits)" on the end?

Done.

Originally Posted by gd_barnes

I found one part in the Definitions section that confused me when returning to the effort after a couple years away. For the pink definition (over 140 digits), you state: "Pink with or without name code". Later in the same sentence you state "Free for reservation".

This gave me the impression that all pink squares were free for reservation even if they had a name code in then. I quickly realized that those were truly reserved and I needed to ask someone to release them if I wanted to work on them.

I think the pink definition needs to be split up onto two separate lines like the orange definition. One line if it has a name code, it is "blocked for reservation". The other line if without a name code, it is "free for reservation".

Done.

Originally Posted by gd_barnes

One nit-pick: Base 1152 is shown out of order below base 1155. :-)

Done.


Please check if everything is good according to your remarks.
Thank you for your ideas.

[gd_barnes]

Originally Posted by garambois

Please check if everything is good according to your remarks.
Thank you for your ideas.

Looks great!

[garambois]

Originally Posted by gd_barnes

Jean-Luc,

This is the idea I was referring to a couple days ago.

I've noticed that the cutoff for the size-limit of the bases on your pages seems to vary quite a bit. On the extreme small end, there is base 20. Its largest exponent of 100 is only 131 digits. On the extreme large end, there is base 99. Its largest exponent of 100 is 200 digits!

This largest size seems to vary between 131 and 200 digits throughout the table. But most bases, especially the small bases <= 10 tend to cutoff around 160-165 digits. Not very many are > 180 digits.

What this does is skew the primes %. Notice that for bases ~20-30, that percentage is unusually high. For bases ~80-100, that percentage is unusually low. These two ranges of bases are on the extreme small or large end of the largest exponent. This causes the unusual percentages.

Also, not having the exponents on the smaller end means we are not testing some that could be interesting to the project.

So I propose this: Can we add exponents up to 160 digits for all bases on the project?

This would involve additions to 22 bases: Bases 20 thru 37 (14 bases), and single bases 288, 338, 385, 392, 1058, 1152, 1155, and 1250.

Bases 20 thru 30 would be the most interesting because they would have the most additions due to their small current cutoff of only 131 to 148 digits. A majority of the bases would only require an addition of <= 5 exponents.

Let me know what you think. I can start on whatever initialization you think is appropriate.

Gary

We were already operating on this principle at the beginning of the project.
But when we were processing the data, we found it easier to harmonize the largest exponents of each base, because it was easier to remember and it simplified the discussions and even the programs.
So we decided to work in "bearings" (I hope I have the good word here !).
On the other hand, we can make the jump less brutal, because for base 19, we go up to exponent 140 and for base 20, we go up to exponent 100.
In the first instance, we can consider an intermediate bearing and put bases 20 to 40 up to exponent 120 for example.

But here we have a big question for all the participants in the project and especially Edwin : Are you willing to do the calculations afterwards ?

[garambois]

Originally Posted by EdH

Here is a list of all 12 digit primes that appear in more than one sequence (excluding merges) throughout the entire set of tables (as far as I can tell):

109964639887,193,22,263
...
...

392293758937,42,23,2984

Some manual editing was done. I hope I didn't introduce any errors this time.

Thank you very much Edwin.
I'll be checking very carefully tomorrow night, as the time is moving fast and unfortunately it's already 9:30 at our house.
I didn't think there would be so many 12-digit couples !
When you say "throughout the entire set of tables", do you mean "throughout the entire set of bases" ?

[EdH]

Originally Posted by garambois

. . .
But here we have a big question for all the participants in the project and especially Edwin : Are you willing to do the calculations afterwards ?

I would be willing to help, at least initializing them, if needed. This would include the same parity sequences as I'm already working. However, keep in mind that if we make this change prior to your data gathering, the present set may be "watered down" a bit.

Originally Posted by garambois

Thank you very much Edwin.
I'll be checking very carefully tomorrow night, as the time is moving fast and unfortunately it's already 9:30 at our house.
I didn't think there would be so many 12-digit couples !
When you say "throughout the entire set of tables", do you mean "throughout the entire set of bases" ?

"Entire set of tables," means all sequences of all bases represented in all the tables. However, this is based on the status of all the sequences at the last update I did. Obviously, the terminated sequences stay the same, but there is more change in the open-ended sequences than I realized a while ago. I have all the sequences in a local directory and when I run a full update I see a lot of sequences being updated, which means my local last line is different from the db last line. I used to be able to run a full update in a couple hours, but with the current db limitations, I've spread that out to over 24 hours.

[EdH]

As to the project home page, I will echo Gary. I agree, it "Looks great!"

[gd_barnes]

Originally Posted by garambois

We were already operating on this principle at the beginning of the project.
But when we were processing the data, we found it easier to harmonize the largest exponents of each base, because it was easier to remember and it simplified the discussions and even the programs.
So we decided to work in "bearings" (I hope I have the good word here !).
On the other hand, we can make the jump less brutal, because for base 19, we go up to exponent 140 and for base 20, we go up to exponent 100.
In the first instance, we can consider an intermediate bearing and put bases 20 to 40 up to exponent 120 for example.

But here we have a big question for all the participants in the project and especially Edwin : Are you willing to do the calculations afterwards ?

I feel that making the jump less brutal is a great way to go! Here is something that could be considered:

Bases 20,21: exponent 125 (If we only go to exponent 120, we still miss a few <= 160 digits.)
Bases 22,23: exponent 120
Bases 24,26: exponent 115
Bases 28 to 31: exponent 110
Bases 33 to 37: exponent 105
Bases 288, 338, 385, and 392: exponent 65
Bases 1058, 1152, 1155, and 1250: exponent 55

If you feel the jumps are too small, maybe combine into: Bases 20,21 to exponent 125, bases 22 to 26 to exponent 120, and bases 28 to 37 to exponent 110. The larger bases jumps would fit right in with the current smaller jumps on larger bases.

I have already initialized all same-parity sequences that begin at <= 160 digits on all of these bases, terminating a few. I have also initialized opposite-parity sequences that begin at <= 160 digits for bases 20 and 21. There are not many iterations that can be added at this point for some of the larger ones on opposite-parity.

If you agree we can do this, I will continue initializing all that I can in a coordinated effort with Ed and anyone else who wishes to help.

[garambois]

Originally Posted by gd_barnes

If you feel the jumps are too small, maybe combine into: Bases 20,21 to exponent 125, bases 22 to 26 to exponent 120, and bases 28 to 37 to exponent 110. The larger bases jumps would fit right in with the current smaller jumps on larger bases.

I have already initialized all same-parity sequences that begin at <= 160 digits on all of these bases, terminating a few. I have also initialized opposite-parity sequences that begin at <= 160 digits for bases 20 and 21. There are not many iterations that can be added at this point for some of the larger ones on opposite-parity.

If you agree we can do this, I will continue initializing all that I can in a coordinated effort with Ed and anyone else who wishes to help.

Bases 20 to 25 to exponent 125
Bases 26 to 30 to exponent 120
Bases 31 to 40 to exponent 110
Bases 288, 338, 385, and 392: exponent 65
Bases 1058, 1152, 1155, and 1250: exponent 55

The above extensions seem to me to be a good compromise : I have changed your proposal a bit.
I will make these extensions in a few days.

Originally Posted by EdH

I would be willing to help, at least initializing them, if needed. This would include the same parity sequences as I'm already working. However, keep in mind that if we make this change prior to your data gathering, the present set may be "watered down" a bit.

If we make these changes before the summer data gathering, indeed, the present set may be "watered down" a bit.
But what matters is the number of points that we will have in the absolute, that is to say the number of sequences that will end with a prime number, especially if this prime number is <100.

Originally Posted by EdH

"Entire set of tables," means all sequences of all bases represented in all the tables. However, this is based on the status of all the sequences at the last update I did. Obviously, the terminated sequences stay the same, but there is more change in the open-ended sequences than I realized a while ago. I have all the sequences in a local directory and when I run a full update I see a lot of sequences being updated, which means my local last line is different from the db last line. I used to be able to run a full update in a couple hours, but with the current db limitations, I've spread that out to over 24 hours.

Thank you very much for these explanations Edwin.

[gd_barnes]

Originally Posted by garambois

Bases 20 to 25 to exponent 125
Bases 26 to 30 to exponent 120
Bases 31 to 40 to exponent 110
Bases 288, 338, 385, and 392: exponent 65
Bases 1058, 1152, 1155, and 1250: exponent 55

The above extensions seem to me to be a good compromise : I have changed your proposal a bit.
I will make these extensions in a few days.

If we make these changes before the summer data gathering, indeed, the present set may be "watered down" a bit.
But what matters is the number of points that we will have in the absolute, that is to say the number of sequences that will end with a prime number, especially if this prime number is <100.

Thank you very much for these explanations Edwin.

Sounds like a great compromise! I look forward to it.

It won't be watered down too much if we get them mostly initialized by the end of June, which I plan to do. Bases 20, 21, and 22 are now initialized for all parity exponents <= 160 digits. Bases >= 23 are all initialized for same-parity exponents <= 160 digits.

I will continue working my way up for opposite-parity exponents for bases >= 23 and keep you posted.

[RichD]

Base 223 can be added to the table at the next update.