mersenneforum.org  

Go Back   mersenneforum.org > Factoring Projects > Aliquot Sequences

Reply
 
Thread Tools
Old 2019-03-18, 02:20   #177
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
"name field"
Jun 2011
Thailand

22×11×223 Posts
Default

Quote:
Originally Posted by VBCurtis View Post
I have a new appreciation for the power of 2^3*3*5 to rapidly drive a sequence.
"Never underestimate D3!"

(it was my motto here for a while, some time ago)
LaurV is online now   Reply With Quote
Old 2019-03-18, 18:26   #178
garambois
 
garambois's Avatar
 
"Garambois Jean-Luc"
Oct 2011
France

24×43 Posts
Default

Quote:
Originally Posted by VBCurtis View Post
13^12 released.
162 digits, C160 that withstood 2t45 ECM.
162 digits !!!
Thank you...

Please, have you checked if there is a merger ?
garambois is online now   Reply With Quote
Old 2019-03-18, 20:05   #179
VBCurtis
 
VBCurtis's Avatar
 
"Curtis"
Feb 2005
Riverside, CA

507510 Posts
Default

Doesn't factordb do that automatically when the sequence is updated?
I did nothing to check for a merger.
VBCurtis is offline   Reply With Quote
Old 2019-03-18, 20:52   #180
garambois
 
garambois's Avatar
 
"Garambois Jean-Luc"
Oct 2011
France

12608 Posts
Default

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 !
garambois is online now   Reply With Quote
Old 2019-03-18, 23:11   #181
VBCurtis
 
VBCurtis's Avatar
 
"Curtis"
Feb 2005
Riverside, CA

117238 Posts
Default

I see. No merger, then- I did all the factoring myself up to 162 digits, no magical factorDB jump!
VBCurtis is offline   Reply With Quote
Old 2019-03-19, 07:58   #182
garambois
 
garambois's Avatar
 
"Garambois Jean-Luc"
Oct 2011
France

24·43 Posts
Default

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 !
garambois is online now   Reply With Quote
Old 2019-03-19, 09:31   #183
kar_bon
 
kar_bon's Avatar
 
Mar 2006
Germany

24·3·61 Posts
Default

W.Creyaufm├╝ller gave some lists with C9/C30/C60/C80 indices of ali-seqs: 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.
kar_bon is offline   Reply With Quote
Old 2019-03-19, 11:08   #184
garambois
 
garambois's Avatar
 
"Garambois Jean-Luc"
Oct 2011
France

68810 Posts
Default

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 yo-yo" !
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 !)
garambois is online now   Reply With Quote
Old 2019-03-19, 15:27   #185
kar_bon
 
kar_bon's Avatar
 
Mar 2006
Germany

24·3·61 Posts
Default

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.
kar_bon is offline   Reply With Quote
Old 2019-03-20, 06:26   #186
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
"name field"
Jun 2011
Thailand

231248 Posts
Default

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...
LaurV is online now   Reply With Quote
Old 2019-03-20, 06:42   #187
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
"name field"
Jun 2011
Thailand

22·11·223 Posts
Default

Quote:
Originally Posted by garambois View Post
In addition, there can be a multitude of C30s or C60s for a single OE sequence that "plays the yo-yo"
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). Low-digits lists are huge. If two sequences "play yo-yo", 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 10-digits 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).
LaurV is online now   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Broken aliquot sequences fivemack FactorDB 46 2021-02-21 10:46
Broken aliquot sequences schickel FactorDB 18 2013-06-12 16:09
A new theorem about aliquot sequences garambois Aliquot Sequences 34 2012-06-10 21:53
poaching aliquot sequences... Andi47 FactorDB 21 2011-12-29 21:11
New article on aliquot sequences schickel mersennewiki 0 2008-12-30 07:07

All times are UTC. The time now is 10:44.


Wed Dec 8 10:44:05 UTC 2021 up 138 days, 5:13, 1 user, load averages: 0.82, 1.14, 1.27

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.