Aliquot sequences that start on the integer powers n^i

[garambois]

Originally Posted by EdH

I totally glossed over the i0=i0. Very unobservant of me. It isn't something to note. Rather I wonder if I should provide a filter to remove it from future listings. I probably won't since we are aware of it, and as you say, it isn't a merger, just a hit with the 80 digit file.

I don't think it's worth removing it from the list, on the contrary, it makes us aware of it !

Originally Posted by EdH

Speaking of the 80 digit file, I'm at 20k of the downloads. I ran my termination detection across those I already had at the time, with no hits, but if the AllSeq.txt from the Blue Page is anything near current, I shouldn't get any hits at this time. That may not be true of merges within the AllSeq.txt. If nothing has changed in merge detection for the Blue Page, it is quite possible (maybe even probable) that there will be undetected merges. That's one of the next scripts I'll be working on.

I still need to find a way to compare last lines, so I can limit updates to those sequences that have changed. Then I can do full set updates in a much more timely manner. I'm actually going to be doing that with my table sets, as well. In the past, I've been updating the full set by downloading the entire .elf for any that weren't terminated. But, the number of tables (and, therefore sequences) has grown considerably since then. As soon as I do another full update of the table .elfs, I'll work on an 80 digit file for them, too.

OK, thanks !

Originally Posted by EdH

My "farm" is quite tied up with a larger job than I expected, or should have tried. It may well be into next month before I can even free the bulk of the machines and then my main machine will be busy for a long time with the LA, if I'm able to actually do it. Otherwise, I could run the c151 for 27000. I wonder, since it is an open sequence of the main project, if we might make a case for it to become a Team Project like 276, 3408, 3366 and 4788. All of those mentioned are at uncomfortably high composites. Maybe we could make a case for working this one, in that it is the only known open-ended sequence of its type and would offer some smaller composites for those interested in the Team Projects, but turned away by the sizes.

Edit: I was thinking of a different sequence. Please disregard the struck-out text. I'll go back into seclusion now (at least for a while). The one I was confusing with 27000 is 18528 which is the merge for 29^15, which was expected to terminate in a manner consistent with all the odd powered base 29 sequences. In light of that, would it be of interest to try for a Team Effort for that main project sequence?

OK, seen. Personally, I do not feel the right to answer this question since in general, I do not participate in the collective effort to calculate the very large sequences which are reserved for a Team Effort.
I therefore let other possible people give their opinion on this question.

[garambois]

Originally Posted by EdH

Let's see if I can redeem myself a little from that last oops. . .

I have attached a list of the C80s for all the open sequences represented in all the tables. Additionally, I found several merges within the tables:

5^26:i221 merges with 3^10:i7 

3^204:i1053 merges with 7^96:i1260 

37^18:i1428 merges with 12^15:i292 
15^42:i810 merges with 12^15:i285 

13^30:i728 merges with 385^6:i250 
12^35:i371 merges with 385^6:i235 

12^43:i489 merges with 14^7:i21 

37^8:i150 merges with 17^4:i20 

7^20:i1345 merges with 5^22:i269 
20^37:i1855 merges with 5^22:i269 
79^52:i2041 merges with 5^22:i269 

11^24:i1993 merges with 385^4:i395 

1155^6:i100 merges with 3^28:i428

As can be seen, three other sequences merge with 5^22:i269. I did not run down the merges between those three. There are also a couple others with multiple merges.

I think I may be taking a break. This last endeavor took a lot more manual intervention than expected. . .

WAOUH AGAIN !

I had never been aware of such a phenomenon ! This is extremely curious, especially for 5^22:i269 !
I think that here you may have opened up a new field of research in our project !

But I notice that all the sequences in this list merge with sequences from the main project.
Have you tried to do a search if we don't have the following case :
n^j:ixxx merges with m^k:iyyy (ixxx and iyyy merge indexes)
with the sequence m^y which does not merge with a sequence of the main project ?

And for the attached file, I keep it carefully, because I plan to write a program in the next few days that generates precisely this file.
It's wonderful to be able to check the correct functioning of a program by comparison! Many thanks.

[garambois]

Originally Posted by EdH

I've attached a new C80 list. I believe it has 51 fewer sequences than the 2020 list. All are unique and open-ended. I did not add a preface to the list. Feel free to make full use of it.

Of note, the Blue Page provided one sequence (1750944) in its AllSeq.txt which has not yet reached 80 digits. All the rest seemed to be what was expected.

Thanks a lot for all this !

I have two remarks :

1) 51 sequences less than on the 2020 list sounds like a lot, but why not ? I'll check it on my side with my own program in the coming days.

2) I think we have a problem with the sequence 1750944.
On factordb, the last term caculated is index 1080 (75 digits).
On the blue page, it is indicated that the last term calculated is that of the index 1655 (144 digits).
I don't understand what's going on, there's bound to be an error somewhere !

[garambois]

Originally Posted by EdH

578^46 has turned green.

OK, thank you.
Next update : today but I don't know what time because there is a lot to fix and check. And there are bases to add, to extend ...

[garambois]

Originally Posted by EdH

Ok, I have some scripts that allow me to check the entire set of tables for sequences that merge. Then, they check to see if the merge is already listed in a table and provide a list of those already within the tables (found) and a list of those not already within the tables (missing). They then list those two sets:

These merges were already present:
31^4:i2 merges with 14100:i2
31^18:i241 merges with 25396:i984

I did just a few spot checks and all "seemed" accurate, but please check them for validity.

I will need to do more work on the scripts before I post them (possibly combining them into one), but I wanted to get the above to you for use for the next update.

Edit: If a new merge has replaced an old merge, it should just show as listed in the "not found" group, since the index numbers will have been different.

I think I found an error in "These merges were already present:".
But it's very curious, it seems to be the only error.
In the tables, for base 31, there are 3 fusions.
The fusion of 31^36 is missing !
I don't know why your program couldn't find it ???

Just for information : I've been working for 3 hours and still haven't started the updates yet.
I have only done error checking and research for now ! And I haven't finished.
So I don't know if the update will be done today.
Maybe tomorrow...

[Happy5214]

Originally Posted by garambois

2) I think we have a problem with the sequence 1750944.
On factordb, the last term caculated is index 1080 (75 digits).
On the blue page, it is indicated that the last term calculated is that of the index 1655 (144 digits).
I don't understand what's going on, there's bound to be an error somewhere !

I checked it with aliqueit, and it failed validation at index 1068. I reported it in the FactorDB forum.

[garambois]

Originally Posted by Happy5214

I checked it with aliqueit, and it failed validation at index 1068. I reported it in the FactorDB forum.

Many thanks !

[EdH]

Originally Posted by garambois

WAOUH AGAIN !

I had never been aware of such a phenomenon ! This is extremely curious, especially for 5^22:i269 !
I think that here you may have opened up a new field of research in our project !

But I notice that all the sequences in this list merge with sequences from the main project.
Have you tried to do a search if we don't have the following case :
n^j:ixxx merges with m^k:iyyy (ixxx and iyyy merge indexes)
with the sequence m^y which does not merge with a sequence of the main project ?

And for the attached file, I keep it carefully, because I plan to write a program in the next few days that generates precisely this file.
It's wonderful to be able to check the correct functioning of a program by comparison! Many thanks.

I think this might be less extraordinary than its first impression. The other sequences merge at different values with each other and then the one with lowest connection with the smallest valued sequence merges and all take on the lowest value. I think it's just a small portion of the genealogy work we did long ago with certain sequences capturing many others along the way. (Or, maybe I'm missing something early in my morning.)

Originally Posted by garambois

Thanks a lot for all this !

I have two remarks :

1) 51 sequences less than on the 2020 list sounds like a lot, but why not ? I'll check it on my side with my own program in the coming days.

2) I think we have a problem with the sequence 1750944.
On factordb, the last term caculated is index 1080 (75 digits).
On the blue page, it is indicated that the last term calculated is that of the index 1655 (144 digits).
I don't understand what's going on, there's bound to be an error somewhere !

I plan to seek out each lost sequences and run down the "why."

Originally Posted by garambois

I think I found an error in "These merges were already present:".
But it's very curious, it seems to be the only error.
In the tables, for base 31, there are 3 fusions.
The fusion of 31^36 is missing !
I don't know why your program couldn't find it ???

Just for information : I've been working for 3 hours and still haven't started the updates yet.
I have only done error checking and research for now ! And I haven't finished.
So I don't know if the update will be done today.
Maybe tomorrow...

I will have to look into this.

Originally Posted by Happy5214

I checked it with aliqueit, and it failed validation at index 1068. I reported it in the FactorDB forum.

Darn! I had intended to run Aliqueit against all the sequences before compiling the list and totally forgot about it.

Thanks for looking after me, Happy5214.


As to the possible Team Project suggestion, I'll look into this at some point.

[EdH]

Originally Posted by garambois

. . .
It's wonderful to be able to check the correct functioning of a program by comparison! Many thanks.

This part is especially exciting to me. Verification, whether it shows success or failure, is important to me in my scripts and programs.

I have a script running Aliqueit against all the sequences ATM. It's much slower than some of my other work, but should be done today.

I'll be looking at the other things as well, hopefully today.

[EdH]

Originally Posted by garambois

I think I found an error in "These merges were already present:".
But it's very curious, it seems to be the only error.
In the tables, for base 31, there are 3 fusions.
The fusion of 31^36 is missing !
I don't know why your program couldn't find it ???
. . .

Ah, yes! The reason it is not found is because a fresh copy of your 2020 80 digit file only goes to 3M, and 3762570 is above that cut. I have a local file which has that entry added, so it is found against that file, but not against the original. The list I provided also ends prior to 3M.

[VBCurtis]

Originally Posted by EdH

As to the possible Team Project suggestion, I'll look into this at some point.

When you're ready to do some work on that sequence, make a thread for it in the same place as the 3366 and 4788 threads. Sean and I will surely help with ECM and other work- as you observe, most of the current team sequences are over 200 digits and rather difficult to work on.