20190318, 02:20  #177 
Romulan Interpreter
"name field"
Jun 2011
Thailand
9,787 Posts 

20190318, 18:26  #178 
"Garambois JeanLuc"
Oct 2011
France
2^{3}×5×17 Posts 

20190318, 20:05  #179 
"Curtis"
Feb 2005
Riverside, CA
3×1,667 Posts 
Doesn't factordb do that automatically when the sequence is updated?
I did nothing to check for a merger. 
20190318, 20:52  #180 
"Garambois JeanLuc"
Oct 2011
France
1010101000_{2} Posts 
Yes, FactorDB do that automatically when the sequence is updated.
But it is then time to report it to me so that I can post it on my own web page. It is quite easy to see if FactorDB has merged the sequence with another one he already knew. If, for example, you have done the calculations up to 120 digits on your computer and you report your results in FactorDB, and if FactorDB suddenly indicates that the aliquot sequence goes up to 162 digits, it means that there has been a merger. On the other hand, if you have done the calculations yourself up to 162 digits and you report the sequence in FactorDB, and you find that the last term of the sequence in FactorDB is the same as the last term of your own calculation on your computer, there has been no merging. If there has been a merger, then we have to find with which sequence did this happen. Sometimes it can be a little laborious... at least for me ! 
20190318, 23:11  #181 
"Curtis"
Feb 2005
Riverside, CA
3×1,667 Posts 
I see. No merger, then I did all the factoring myself up to 162 digits, no magical factorDB jump!

20190319, 07:58  #182 
"Garambois JeanLuc"
Oct 2011
France
1250_{8} Posts 
Thank you !
So I don't have to look with which sequence there is a merging for sequence 13^12. I know how to do if there is a merging with a sequence that starts on a number less than 3*10^6, thanks to the explanations of kar_bon and thanks to this page : https://www.rechenkraft.net/aliquot/AllSeq.txt But to find the mergers with the other FactorDB sequences already calculated, which start with numbers greater than 3*10^6, I don't know how to do it ! 
20190319, 09:31  #183 
Mar 2006
Germany
3^{2}×5^{2}×13 Posts 
W.Creyaufmüller gave some lists with C9/C30/C60/C80 indices of aliseqs: so if a seq. drops down to a C25, you could look when it reaches C30 again, if this C30 was reached by another seq. Only problem is, those data files are very outdated.
To keep current, every open seq has to be scanned about those say C30/C60 values and generate this new list. This is independent of only the last index of a seq. like in AllSeq.txt, where those last values could differ because of only updating a small amount of all open seqs. 
20190319, 11:08  #184 
"Garambois JeanLuc"
Oct 2011
France
2^{3}×5×17 Posts 
It would indeed be very useful to have a recent list for the C30 and C60 of all numbers generating OE sequences up to at least 10^7 !
But how can FactorDB be efficiently scanned to achieve this ? In addition, there can be a multitude of C30s or C60s for a single OE sequence that "plays the yoyo" ! For example, if a sequence encounters a C60, if it then goes up higher and goes down to 60 digits afterwards, it will be necessary to store this second C60 in the list. Because, if there is a fusion of another sequence with this one, there is no guarantee that the fusion will take place before the first C60. This can happen later. The list must always show the last C30 and C60 given by FactorDB. (I hope my message is clear with my bad English !) 
20190319, 15:27  #185 
Mar 2006
Germany
3^{2}×5^{2}×13 Posts 
The only way I see is to download all ELFs from open seqs and run a script over these files, scanning for those C30/C60. And perhaps all occurences of a (upgoing) C60 is relevant, not only the last one in a sequence.
Example: 158814 > C60's at index 934, 2200 and 2722 So a merge could happen (before) the first C60 but you only be aware until the last C60, ~1800 indices later if only the last C60 will be listed. 
20190320, 06:26  #186 
Romulan Interpreter
"name field"
Jun 2011
Thailand
263B_{16} Posts 
I have my own 10, 12, 15, 20, 30, 50, 80 digits lists. That is the first x digits number that some sequence reach, for which I store the "smallest starter" and the "longest sequence". They are huge files, but they can be shared if someone needs. Better is if you have trouble finding a merge, post it and I may help...

20190320, 06:42  #187 
Romulan Interpreter
"name field"
Jun 2011
Thailand
9,787 Posts 
You always store the first. In fact, there are no merges "so high", all merges happen at very low digit count. The reason to store higher lists (people use to keep 80 and 100) is that the search is easier (less items in the list). Lowdigits lists are huge. If two sequences "play yoyo", there is still a "lowest point" where they merge, which is then (after raising) the "first" reach. It doesn't make sense to store all crosses. For example, you have two sequences that reach 10, 20, 30, 40 digits without merging, you will have stored one number for each, at 10, 20, 30, etc. If then both drop and merge, if at least one of them dropped below 7 digits, then the next 10digits cross is already in the list, from the sequence starting with the last drop. If they drop no lower than 9 digits, then merge, and raise back (as one sequence) to10, 20, 30, 40, you will not detect this, as the new cross into the 10, etc, will not be recorded, because there is no record for sequences starting with 9 or more digits. But immediately when they cross to 50 digits, it will be detected (and recorded).

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Broken aliquot sequences  fivemack  FactorDB  46  20210221 10:46 
Broken aliquot sequences  schickel  FactorDB  18  20130612 16:09 
A new theorem about aliquot sequences  garambois  Aliquot Sequences  34  20120610 21:53 
poaching aliquot sequences...  Andi47  FactorDB  21  20111229 21:11 
New article on aliquot sequences  schickel  mersennewiki  0  20081230 07:07 