[QUOTE=EdH;571862]Third one is at index 2, also.

Glad to be helpful. I'm looking forward to your findings.[/QUOTE]




Thanks a lot.
These calculations would have really taken me a lot more time !

[QUOTE=garambois;571922]Thanks a lot.
These calculations would have really taken me a lot more time ![/QUOTE]You're quite welcome.

Have you been looking into updating the 80 digit file? If not, you might want to wait just a bit longer. I'm playing with some stuff that will probably allow me to create an updated file in the near future. If this all works well, I hope later updates will be even easier and maybe even C30/C60, etc. will be easy.

Yes, I am planning to update the C80 digit file very quickly. But the scan of the 27,000 sequences takes several days (21 days !).
I will also create a C80 file for all the Open End sequences in our project, as advertised here :
[URL]https://www.mersenneforum.org/showthread.php?t=23612&page=65#714[/URL]
Please keep me posted if you are doing any work in this direction as well !

[QUOTE=garambois;571938]Yes, I am planning to update the C80 digit file very quickly. But the scan of the 27,000 sequences takes several days (21 days !).
I will also create a C80 file for all the Open End sequences in our project, as advertised here :
[URL]https://www.mersenneforum.org/showthread.php?t=23612&page=65#714[/URL]
Please keep me posted if you are doing any work in this direction as well ![/QUOTE]
I'm doing some experiments now, that will provide some better info, but initial results seem to point to me being able to get all 27645 sequences in a timely manner, and then use the local set for all my "playing."

My overall intention is to create a local set of all open sequences (<3M). Then, create scripts (or C++ programs) for the following:
- Update entire set by comparing last lines and only retrieving sequences that have changed since the last time run - to be used only a couple times a year.
- Create lists of last occurrences of various digit sizes (C9/C30/C60/C80).
- Check for merges against local sequences rather than the db. Since the C80 listing will reflect data harvested from the local set, there should not be a need to check against the db.
- Whatever else I may think of.

I already have a local copy of all the sequences in the base tables, and a method to update all open sequences in all the tables. I should be able to create a script to harvest C9/C30/C60/C80 lists from that, as well. I will consider it.

Of course, all this hinges on my ability to actually create the scripts. But, I will update here as I progress.

Edit: It looks like I'm able to d/l 1000 .elfs in a little over two hours without the db being anywhere near complaining. I don't plan to let it run unattended overnight, so I'm probably looking at a few days to complete the set. But, I don't need the full set to begin writing scripts.

Addendum to last post
 

I also intend to search the new set for any new merges or terminations that may have occurred. I plan to have that done by the script(s), to try to remove as much as possible the need for manual intervention.

I do wonder how much the list will have really changed over the past 9 months. Most of those sequences were well over 80 digits and probably few fell that far again. A quick examination of the first 100 sequences didn't reveal any difference between a new list and last year's. But, then, again, most of the work was probably in the higher sequences.

Base 47 can be added at the next update - to i=45.. There is still many computations to be done. There is also a merge but I didn't record it because we have this new tool.

450^49 and 450^50 have turned green.

578 is finished (green) through 578^50, with the exceptions of 578^46, 578^49 and 578^50, which are in work.

[QUOTE=RichD;571997]Base 47 can be added at the next update - to i=45.. There is still many computations to be done. There is also a merge but I didn't record it because we have this new tool.[/QUOTE]

Correction: i through 75.

[QUOTE=RichD;571997]Base 47 can be added at the next update - to i=45.. There is still many computations to be done. There is also a merge but I didn't record it because we have this new tool.[/QUOTE]
Actually, it shows two:
[code]
Running base 47 from 1 through 75 . . .
47^4:i1 merges with 106080:i0
47^40:i1455 merges with 875060:i6
Run took 92 seconds.
[/code]I will try to run it against the entire set of tables later today and make a list of any merges not already noted.

[QUOTE=EdH;571949]I'm doing some experiments now, that will provide some better info, but initial results seem to point to me being able to get all 27645 sequences in a timely manner, and then use the local set for all my "playing."

My overall intention is to create a local set of all open sequences (<3M). Then, create scripts (or C++ programs) for the following:
- Update entire set by comparing last lines and only retrieving sequences that have changed since the last time run - to be used only a couple times a year.
- Create lists of last occurrences of various digit sizes (C9/C30/C60/C80).
- Check for merges against local sequences rather than the db. Since the C80 listing will reflect data harvested from the local set, there should not be a need to check against the db.
- Whatever else I may think of.

I already have a local copy of all the sequences in the base tables, and a method to update all open sequences in all the tables. I should be able to create a script to harvest C9/C30/C60/C80 lists from that, as well. I will consider it.

Of course, all this hinges on my ability to actually create the scripts. But, I will update here as I progress.
[/QUOTE]


I will follow your work closely if you share it with us here.

At the moment, I'm having a hard time figuring out the usefulness of creating a list of the last occurrences of various digit size : C9 / C30 / C60 / C80.
Isn't it enough to create C80 ? With C80, you are sure to find the right fusion sequence. The risk that a C9 belongs to two sequences of the main project does not seem negligible to me, but it should be checked.
Also, if a sequence is yo-yoing, there is no reason the merge occurred during the last "low peak". The merger may have occurred on an earlier "low peak" (Merges almost always occur on the low peaks).
But you must have your reasons for wanting to create lists of last occurrences of various digit sizes (C9/C30/C60/C80).



[QUOTE=EdH;571949]
Edit: It looks like I'm able to d/l 1000 .elfs in a little over two hours without the db being anywhere near complaining. I don't plan to let it run unattended overnight, so I'm probably looking at a few days to complete the set. But, I don't need the full set to begin writing scripts.[/QUOTE]


1000 downloads of .elf in 2 hours : This is not at all what I experienced in April 2020. I had instead a speed of an .elf file in 60 seconds.
So this is very good news, maybe factodb's server is much faster now. I will give it a try over the next week.



[QUOTE=EdH;571966]I also intend to search the new set for any new merges or terminations that may have occurred. I plan to have that done by the script(s), to try to remove as much as possible the need for manual intervention.

I do wonder how much the list will have really changed over the past 9 months. Most of those sequences were well over 80 digits and probably few fell that far again. A quick examination of the first 100 sequences didn't reveal any difference between a new list and last year's. But, then, again, most of the work was probably in the higher sequences.[/QUOTE]


There really isn't a lot of change in a year. Each year you have to delete the sequences that have ended or that have merged with a smaller one from the main project.
These are the ones that are reported on the last pages of this topic :
[URL]https://www.mersenneforum.org/showthread.php?t=11837[/URL]

@RichD : Thank you very much for your work on base 47.

@Edwin : Thank you very much for your work on bases 450 and 578.