Aliquot sequences that start on the integer powers n^i

[EdH]

OK, here's the latest C80 listing. I think I've done all the checking needed, but of course validation is always welcome.

[garambois]

OK, page updated.

Biggest update in the history of the project !
Thank you all for your help !
Lots of little issues were fixed over 10 hours of work, not to mention all the time spent communicating with you here on the forum !
Thank you for reporting any errors regarding your work, your reservations, your mergers or another thing !
I really hope I haven't forgotten anything, and made no mistakes !

Bases with additions of exponents : 15, 17, 18, 19, 20, 21, 23, 26, 29, 30, 31, 33, 34, 35, 37, 41, 42, 200, 220, 284, 439, 496, 770, 1155, 8128, 33550336

Added bases : 34, 35, 42, 43, 47, 578, 8589869056, 2*3*5*7*11*13*17*19*23, 2*3*5*7*11*13*17*19*23*29, 2*3*5*7*11*13*17*19*23*29*31, 2*3*5*7*11*13*17*19*23*29*31*37

The last four base additions relate to some new findings that I will be presenting to you in a few days.


@Edwin : Thanks for correcting post #841.

[garambois]

Originally Posted by EdH

OK, here's the latest C80 listing. I think I've done all the checking needed, but of course validation is always welcome.

Many thanks Edwin !

[EdH]

Glad I'm of help.

I have added a post to see if there is interest for a team project on the number 29^15 merged with. There is already a little. We'll see if there is more.

This brings me to another thought that I hadn't as of yet: If we merge with a sequence from the main project, we should check that it is not a reserved sequence, if we intend to continue with it. I think most of us have stopped when a merge was discovered because it met our limit, but we've raised our limit in many cases. I bring this up in case it hasn't been thought of, yet.

[Happy5214]

Before the page gets too long, we may want to think about how we want to organize the bases. My suggestion is to sort them into different categories based on their form or notability (e.g. primes, 2 times a square, perfect numbers, cycles, primorials, etc.), either by re-sorting them into sections on the page and listing by type or by providing a navigation section near the top with the types that links to the bases, or possibly both. It would be useful to convert the base section headers from <a> to the proper HTML header tags in the process so they could be used as anchors, especially if we use the navigation section idea, and perhaps we should sort all of them under an <h2> header for the data. Honestly, I sort of prefer the latter plan since there's some overlap in the types (e.g. 2 (prime and 2 times a square) and 6 (perfect and primorial)).

[EdH]

Originally Posted by EdH

. . .
This brings me to another thought that I hadn't as of yet: If we merge with a sequence from the main project, we should check that it is not a reserved sequence, if we intend to continue with it. I think most of us have stopped when a merge was discovered because it met our limit, but we've raised our limit in many cases. I bring this up in case it hasn't been thought of, yet.

I ran a reservation check against the lists of merges and found quite a number:

These merges were already present: 
3^10:i15 merges with 1134:i9 Paul Zimmerman 
3^48:i400 merges with 27450:i55 Batalov 
3^204:i1060 merges with 4788:i6 mersenneforum 
5^6:i1 merges with 3906:i0 dleclair 
5^8:i3 merges with 564:i12 Paul Zimmerman 
5^22:i265 merges with 660:i21 Paul Zimmerman 
5^26:i229 merges with 1134:i9 Paul Zimmerman 
6^7:i9 merges with 95280:i20 LaurV 
6^67:i890 merges with 27860:i2 LaurV 
6^81:i703 merges with 388600:i7 LaurV 
7^10:i18 merges with 171040:i1 yafu@home 
7^20:i1345 merges with 660:i25 Paul Zimmerman 
7^96:i1267 merges with 4788:i6 mersenneforum 
11^4:i1 merges with 1464:i0 Christophe Clavier 
12^15:i294 merges with 3366:i2 mersenneforum 
12^35:i380 merges with 3876:i5 Christophe Clavier 
12^43:i488 merges with 2484:i8 Christophe Clavier 
13^30:i728 merges with 3876:i11 Christophe Clavier 
14^7:i21 merges with 2484:i9 Christophe Clavier 
14^13:i262 merges with 167748:i33 yafu@home 
15^4:i3 merges with 3432:i69 Christophe Clavier 
15^8:i77 merges with 147150:i17 yafu@home 
15^12:i3841 merges with 368688:i2 Sergiosi 
15^42:i819 merges with 3366:i2 mersenneforum 
17^4:i21 merges with 1632:i37 Christophe Clavier 
20^7:i60 merges with 7044:i129 schickel 
20^37:i1855 merges with 660:i25 Paul Zimmermann 
22^29:i321 merges with 5208:i6 Christophe Clavier 
23^44:i1830 merges with 7560:i251 Christophe Clavier 
28^21:i4035 merges with 818880:i7 LaurV 
37^18:i1430 merges with 3366:i2 mersenneforum 
79^52:i2041 merges with 660:i25 Paul Zimmermann 
385^6:i244 merges with 3876:i5 Christophe Clavier 
770^3:i29 merges with 165876:i98 yafu@home
2310^1:i0 merges with 1578:i3 Walter Krickau

.

 These merges were not found: 
37^8:i151 merges with 1632:i37 Christophe Clavier 
37^22:i519 merges with 1567300:i0 yafu@home

Most, if not all, of these were probably at a level that we stopped work when they merged, but should we also have a reservation flag in the tables? Some of the reservations are "Contributors" to the tables, but many are not. Should we perhaps have a "Main Project Reservation (MPR)" entry, and keep track of them? I don't think we should check for dropped reservations, but we may want to check any new found merges for existing reservations in the Main Project.

[garambois]

Originally Posted by EdH

I have added a post to see if there is interest for a team project on the number 29^15 merged with. There is already a little. We'll see if there is more.

Yes, I saw this. Thank you very much ! I can't wait to see where this sequence goes ...

Originally Posted by EdH

This brings me to another thought that I hadn't as of yet: If we merge with a sequence from the main project, we should check that it is not a reserved sequence, if we intend to continue with it. I think most of us have stopped when a merge was discovered because it met our limit, but we've raised our limit in many cases. I bring this up in case it hasn't been thought of, yet.

I have asked myself this question before.
I think we should not reserve on our page sequences that merge with a sequence from the main project.
If someone wants to calculate such a sequence, it is infinitely easier if he is going to reserve it in the main project, if it has not yet been reserved before by someone else.

[garambois]

Originally Posted by Happy5214

Before the page gets too long, we may want to think about how we want to organize the bases. My suggestion is to sort them into different categories based on their form or notability (e.g. primes, 2 times a square, perfect numbers, cycles, primorials, etc.), either by re-sorting them into sections on the page and listing by type or by providing a navigation section near the top with the types that links to the bases, or possibly both. It would be useful to convert the base section headers from <a> to the proper HTML header tags in the process so they could be used as anchors, especially if we use the navigation section idea, and perhaps we should sort all of them under an <h2> header for the data. Honestly, I sort of prefer the latter plan since there's some overlap in the types (e.g. 2 (prime and 2 times a square) and 6 (perfect and primorial)).

I have to admit that I am starting to confuse the basics, because there are a lot of them now.
The advantage of the current presentation is that the numbers are arranged in ascending order.
I don't know if I understand your entire message correctly.
If I understand correctly, you are suggesting to leave as it is now, but to add buttons to click at the beginning of the page, on which we could click.
These buttons would be titled "primorial", "perfect", "cycles", '2 times a square ", ....
And when we click on these buttons, it would only reveal the bases included in the category.
Is that your idea ?
I think it's a very good idea !

On the other hand, I am totally unable to realize the code to do this. I will have to ask the great architect of the page, Karsten Bonath, that I do not can never thank enough for all his help.
Can you confirm to me that I understand your idea correctly ?
Does anyone else have an opinion on this matter ?

[garambois]

Originally Posted by EdH

I ran a reservation check against the lists of merges and found quite a number:

 ...
...

 These merges were not found: 
37^8:i151 merges with 1632:i37 Christophe Clavier 
37^22:i519 merges with 1567300:i0 yafu@home

Most, if not all, of these were probably at a level that we stopped work when they merged, but should we also have a reservation flag in the tables? Some of the reservations are "Contributors" to the tables, but many are not. Should we perhaps have a "Main Project Reservation (MPR)" entry, and keep track of them? I don't think we should check for dropped reservations, but we may want to check any new found merges for existing reservations in the Main Project.

Look at post #854 which also gives my opinion on the issue of reserving sequences that merge with sequences from the main project.
But maybe other people will have a different opinion ?

Otherwise, I don't understand why the 37 ^ 8 and 37 ^ 22 sequences are classified under the heading : "These merges were not found:" ?

[garambois]

Originally Posted by EdH

OK, here's the latest C80 listing. I think I've done all the checking needed, but of course validation is always welcome.

I just started running my own program.
I hope we will have the same result !
I also hope there won't be new broken sequences.
Result in a few days, I confirm, it is going much faster than a year ago.
What happiness !
It is even now possible to scan a main project which would consider all sequences <10^7 !

[EdH]

Originally Posted by garambois

. . .
Otherwise, I don't understand why the 37 ^ 8 and 37 ^ 22 sequences are classified under the heading : "These merges were not found:" ?

I did a cut/paste from the earlier posting, at which time they were not yet included. I should have removed those headers. Sorry 'bout that!