Aliquot sequences that start on the integer powers n^i

[garambois]

For Your Information :
I have started the data analysis.
I am also in the process of refining the analysis programs.
I will launch the big summer 2021 scan of all project sequences on Monday, August 9 after 6:00 GMT.
I think I will include some bases that are not yet listed on our page, like 51, 276, 552...
If by that date some of you still manage to finish sequences or initialize other bases, don't forget to let me know and to enter your results on FactorDB so that your last calculations are taken into account.

About the 256-bit limit of Sweety :
It is true, it is not very high and it would be very nice if the limit would be increased to 100 digits minimum as it is usual.
But what is very important for me is that the trivially terminating sequences are all calculated and terminated for all sequences whose first term has less than 120 digits (exponent 56 for base 120).
This way I can copy and paste the whole block at once when I create the new database and I don't have to reorder them, interleave them, sort them manually.
If this is not done, my work time is really increased tenfold and it is exhausting and error-prone.
I prefer to spend my time and energy processing the data...

[Happy5214]

Base 564 can be included in the next update. I'm currently trying to terminate the trivial sequences between 120 and 135 digits, but all of the other initialization work for that base is done. So far, there have been two non-trivial prime terminations.

Originally Posted by garambois

Thank you for your answer.
We had worked this way at the beginning of the project, but at a 120 digit limit.
It was sometimes laborious, because we always had to go and look at the limit exponent we had to work with.
Especially for yoyo, which reserves bases by large packages.
So I simplified it by putting round numbers in stages for the limit exponents.
And that turned out to be more convenient.
Moreover, for the limit exponents, I tried to find a compromise so that the number of digits in the last sequence of a base is not too big.
I know that no one will calculate sequences of more than 160 digits, at least not until the distant future !
But if other contributors want me to adopt the old method again, I will : all limit exponents for a base calculated so that the first term of the sequence has 200 digits.
Current state of opinion :
- Alexander : limit exponent for each base calculated so that the first term of the last sequence of a base has 200 digits
- Yoyo : leave everything as it is now
- Myself : leave everything as it is now except for b bases such as 280<b<1000 : extend to exponent 70

200 digits was simply a suggestion based on the edge of the two-digit base block, which will end up at 200 digits at base 100. I highly doubt we actually want to invest that kind of work extending all bases to 200 digits versus creating new bases. 160 digits is a much more reasonable number IMO. The important part of my answer was fixed digit limits being preferred over fixed exponent limits, not the exact digit limit itself.

Originally Posted by garambois

You are right, the answer seems contradictory !
But I'm really reluctant to create a new category whose bases could then be removed.
But maybe I'm wrong ?
Again, let's make democracy work.
If other contributors give their opinion on the subject, we will make a decision based on the majority that will make it easier for as many people as possible, it seems fair.
Current state of opinion :
- Alexander : add a category including the Open-End sequences of the main project
- Myself : do not add it
On the other hand, if the calculations show that there are really special things happening for these bases, or on the contrary, that nothing is happening at all, this can also make us change our opinion...

Looking ahead to the other two bases from the Lehmer five that I haven't started yet, 660 starts with two non-trivial prime terminations, while 966 has no prime terminations from the 50-digit FactorDB initialization runs.

To counter your argument about these open sequence bases needing to be "special", have we shown the sequences for the primorial bases to be "special"? Even if they don't turn out to be special mathematically, they're of possible interest as a well-defined source of bases to add, and IMHO that's reason alone to categorize it.

(As an aside, we should also add the factorials as a category now that 120 is being initialized.)

[VBCurtis]

After seeing what Sweety did to Gary's projects for years, I'm deleting Sweety's tiny update posts. The one deleted a few posts up covered 3 odd powers to less than 100 digits, nothing of interest.

Sweety-
If you want to avoid having your posts deleted here, wait until you're done with all the sequences of 120^n that you're going to work on. The only exception is an odd power that terminates / merges, since those are considered interesting events. We want one report, NOT daily progress. If that takes you a month or more to complete, that's fine; don't tell us about your work in the meantime.

Also, if you care to report the cofactor length of a sequence you're done with, do it in decimal digits- not bits.

[Aillas]

Originally Posted by EdH

Here is the source for a C++ program. I'm afraid it's probably a bit "amateurish," and it has very little internal commenting, but it should compile on linux with:

* I tried to add an elapsed time function, but for some reason the timing was extremely inaccurate with the several methods I tried, so I left it out.

Here is an updated version of your program. What's new:
- I use Map instead of Vector for faster lookup
- I initialize the Map in the loop that load the file
- Using the map, remove a loop level (From 3 to 2 nested loop)
- Add time counters (Total/Download/Compute)

Here is an output example:

Running base 2577846 from 1 through 1 . . .
Downloading base 2577846^1 : Done
Found the last 80 digit composite in base 2577846: [89222463159839875999432010157696421431341480313103789603011845300916805141579206]
80 digit composite has a matching in base 10528
Downloading base 10528 : Done

2577846^1:i2335 merges with 10528:i2

Total running time   : 49 Seconds : 210 Milliseconds
Downloading file time: 49 Seconds : 114 Milliseconds
Computation only time: 95 Milliseconds

Not tested (compiled on Linux). But It's standard c++.
Not tested with last exponent > 1

Enjoy...

[EdH]

Originally Posted by Aillas

Here is an updated version of your program. . .

Excellent! Thank you!

[RichD]

Originally Posted by garambois

I will launch the big summer 2021 scan of all project sequences on Monday, August 9 after 6:00 GMT.

Can you perform a table update over the weekend so we can spot any deficiencies? Better yet, perhaps you can also flag them in a post here and some of us will try to complete the calculations by Monday afternoon (GMT).

[henryzz]

I am going to take a shot at 6!=720

[garambois]

Originally Posted by Happy5214

Base 564 can be included in the next update. I'm currently trying to terminate the trivial sequences between 120 and 135 digits, but all of the other initialization work for that base is done. So far, there have been two non-trivial prime terminations.

OK, thank you very much.
This base will be added in the next update.

Originally Posted by Happy5214

200 digits was simply a suggestion based on the edge of the two-digit base block, which will end up at 200 digits at base 100. I highly doubt we actually want to invest that kind of work extending all bases to 200 digits versus creating new bases. 160 digits is a much more reasonable number IMO. The important part of my answer was fixed digit limits being preferred over fixed exponent limits, not the exact digit limit itself.

OK, got it.
And I agree with you : better to calculate new bases for now.

Originally Posted by Happy5214

To counter your argument about these open sequence bases needing to be "special", have we shown the sequences for the primorial bases to be "special"? Even if they don't turn out to be special mathematically, they're of possible interest as a well-defined source of bases to add, and IMHO that's reason alone to categorize it.

(As an aside, we should also add the factorials as a category now that 120 is being initialized.)

If you look at conjectures 134, 135, 136 and 140 on this page dedicated to conjectures related to this project, they all talk about bases that are primorial numbers.
That's why I think we can say that the primorial bases play a special role in our project, so they are "special".
In principle, we can also add a category for bases that are factorials when we will have several of them, why not ?
None of these bases can be taken out of this category in the future, no matter what.

[garambois]

Originally Posted by Aillas

Here is an updated version of your program.

Thanks a lot.
But forgive my ignorance, I can't compile this program under Linux, here is what my compiler says :

garambois@floyd:~/sage-9.2$ g++ Alimerge.cpp -o Alimerge
Alimerge.cpp: In function ‘int main(int, char**)’:
Alimerge.cpp:67:5: error: ‘sscanf_s’ was not declared in this scope
     sscanf_s(argv[1], "%d", &base);
     ^~~~~~~~
Alimerge.cpp:67:5: note: suggested alternative: ‘sscanf’
     sscanf_s(argv[1], "%d", &base);
     ^~~~~~~~
     sscanf
  garambois@floyd:~/sage-9.2$

Please, can you help me ?

[garambois]

Originally Posted by RichD

Can you perform a table update over the weekend so we can spot any deficiencies? Better yet, perhaps you can also flag them in a post here and some of us will try to complete the calculations by Monday afternoon (GMT).

Sorry, but I won't have enough time by Monday to update the page again, I'll do that later this week.
Now I'm just focusing on the data analysis.
And this time, the task seems very difficult.
My first visualizations of the data don't show anything that would allow me to formulate new conjectures for the moment : the "obvious" things must have been noticed last year !

However, as a priority, if you initialize new bases, calculate the maximum number of sequences that end trivially, because essentially, the data analysis will focus on whether the sequences belong to this or that branch of the infinite graph of aliquot sequences.
And we only know this membership for sequences that end in cycles or primes.
Of course, the non-trivial sequences that end are even more valuable, but they are so much rarer and harder to find, given the little time left until Monday...
If you have additional computational resources, you can complete the calculations for some trivial sequences of bases 210, 14316, 14264, 14536 or other still unreserved bases.
Otherwise, you can also advance the non-trivial sequences of these unreserved bases to for example 105 or 110 digits. With a little luck, you will finish one or other non-trivial sequence this way.
But in any case, please report here any work you undertake : it would be too bad if several of you were to calculate the same sequence !
And don't forget to tell me about the new initialized bases, I will include them in the general scan on Monday, even if these sequences are not yet added to our project page.

Originally Posted by henryzz

I am going to take a shot at 6!=720

OK, excellent !
Don't forget to let me know if you've finished initializing this base by Monday, August 9 at 6:00 PM (GMT) !

[RichD]

Originally Posted by garambois

Sorry, but I won't have enough time by Monday to update the page again, I'll do that later this week.

I understand. That is a very good visualization tool which I use quite a bit.

Originally Posted by garambois

However, as a priority, if you initialize new bases, calculate the maximum number of sequences that end trivially, because essentially, the data analysis will focus on whether the sequences belong to this or that branch of the infinite graph of aliquot sequences.

Bases 52, 54 and 55 should have all exponents (terms) initialized to at least 80 digits and all 80 digit or less trivial terminating sequences completed. Many will be advanced further by late Monday. I'll put emphasis on expected terminating sequences and raise the initial size to 100 (or more) digits in the next couple days.