Thank you for the kind words and encouragement!

I hope to get enough sequences to 160+ to motivate the creation of a new color on the tables. Perhaps lavender (light purple)? A sort of personal 2023 goal. :)

[QUOTE=VBCurtis;619890]Thank you for the kind words and encouragement!

I hope to get enough sequences to 160+ to motivate the creation of a new color on the tables. Perhaps lavender (light purple)? A sort of personal 2023 goal. :)[/QUOTE]

I'll second that motion! Light purple for 160 digits! :-)

The talk about adding a new color for 160+ digits made me assess how it would fit into our existing WCAG (web accessibility) AA level compatibility, and I discovered that the new version of WCAG changed the contrast formula, thus knocking most of the existing cell background colors slightly out of compliance. Re-reading the standard, it doesn't appear I need a 4.5:1 contrast between the cell background colors like I do between the background colors and the text colors, which will provide more flexibility. All of the out-of-whack contrasts are above 4:1, so they should only require slight adjustments.

Although I like the idea of light purple, after thinking about it more I feel like there would be not enough contrast between the background of a sequence box and the light blue or purple links of that box. So something different than a light blue/light purple box background might be in order for 160 digits if we decided to do that.

[QUOTE=gd_barnes;619591]
Would it make sense to make these a higher priority than the bigger bases?[/QUOTE]
Yes, I think the smaller bases are the priority.
I always keep in mind that base 2 will have to be explored further, and even base 3.
For base 2, I will certainly extend to the exponent 600 when I have more computing resources.

[QUOTE=garambois;620057]Yes, I think the smaller bases are the priority.
I always keep in mind that base 2 will have to be explored further, and even base 3.
For base 2, I will certainly extend to the exponent 600 when I have more computing resources.[/QUOTE]

I posed that question for Yoyo hoping they'd pick up some of the smaller base sequences that are not yet at 140 digits.

I'll take base 3 and base 2 up to 2^600.

Here's the updated CSS, with the new light purple color for 160+ digits. I had to italicize the merge highlights due to WCAG criterion 1.4.1 (the tooltip didn't appear to be enough, which surprised me). I can go on and on about the CSS classes needing longer/more readable/more useful names, but I'll just say the navigation section on the main page should have a [c]<nav>[/c] tag instead of a [c]<section>[/c] tag (it's more semantically correct).

[QUOTE=Happy5214;620204]Here's the updated CSS, with the new light purple color for 160+ digits. I had to italicize the merge highlights due to WCAG criterion 1.4.1 (the tooltip didn't appear to be enough, which surprised me). I can go on and on about the CSS classes needing longer/more readable/more useful names, but I'll just say the navigation section on the main page should have a [c]<nav>[/c] tag instead of a [c]<section>[/c] tag (it's more semantically correct).[/QUOTE]

I'd like to see the contrast between the background and the links before anything is done permanently. See my concern in the last post that I had here.

Here's an example for base 2 with the suggested color codes including the italics for merges (here only as example for n=600):

update 13^46, 13^124, 13^66, all have reached 140+ digits. I added over 1500 terms to 13^66!

[QUOTE=kar_bon;620256]Here's an example for base 2 with the suggested color codes including the italics for merges (here only as example for n=600):[/QUOTE]

Looks great! That's lighter than I had expected so the contrast is good.

A thought: If we did that, it would be white for < 120 digits, dark(ish) orange for 120 digits, medium pink for 140 digits, and finally light purple for 160 digits.

What's odd about that is that it starts out as the lightest color white, jumps dark, and then progresses lighter again as it goes up.

In order to progress from light to dark, 120 and 160 could be reversed like:

White < 120, light purple at 120, medium pink at 140, and dark(ish) orange at 160. And something even darker for 180.

The idea being to turn all of the bases as dark as possible. :smile:

Gary, I like your idea !
This would result in the following code in Karsten's scripts.

Replace :

[CODE] .co-pr {background-color:#7C4;} /* green: seq is done */
.co-op {background-color:#EA0;} /* red: seq is open >120 digits <140 digits */
.co-cy {background-color:#9BF;} /* blue: seq ended in cycle */
.co-me {background-color:#FE0;} /* yellow: seq merges */
.co-pi {background-color:#FAA;} /* pink >140 digits <160 digits */
.co-pu {background-color:#D8B1D4;} /* purple >160 digits */
.head {background-color: lightgrey; font-weight: bold;
[/CODE]
by :

[CODE] .co-pr {background-color:#7C4;} /* green: seq is done */
.co-cy {background-color:#9BF;} /* blue: seq ended in cycle */
.co-me {background-color:#FE0;} /* yellow: seq merges */
.co-pu {background-color:#D8B1D4;} /* purple >120 digits <140 digits */
.co-pi {background-color:#FAA;} /* pink >140 digits <160 digits */
.co-op {background-color:#EA0;} /* red: seq is open >160 digits <180 digits */
.____ {background-color:#____;} /* ___: seq is open >180 digits*/
.head {background-color: lightgrey; font-weight: bold;[/CODE]

It remains to choose the color for the cells >180 digits.
Does anyone have a suggestion ?

PS : I am in the process of doing the full update with all your latest requests.
But FactorDB often crashes.
I may not finish until tomorrow and the cell color changes may not be done yet, until we all agree.

[QUOTE=garambois;620303]Gary, I like your idea !
......
It remains to choose the color for the cells >180 digits.
Does anyone have a suggestion ?
[/QUOTE]

Gary's idea would swap lavender and orange, so orange is the 160+ color? The new color is a nice choice, looks very good.

180!?!?!?? I thought 160 was a stretch! I mean, if you pick a color for 180 I'll make absolutely sure to put it to work.

[QUOTE=garambois;620303]
It remains to choose the color for the cells >180 digits.
Does anyone have a suggestion ?[/QUOTE]

I was somewhat joking about 180 digits. I would suggest not doing that at this point but it's certainly something for several years down the line. Right now, many bases don't have exponents shown for a starting size much above 170 digits with 160 digits being the minimum.

If and when we decide to add a 180 digit color, I feel like it would be better if all sequences were extended up to a starting size of a minimum of 180 digits. That would be a huge change so it's probably best left for the far-off future at this point.

If you and Curtis like the idea of having light purple be 120 digits and dark orange being 160 digits resulting in sizes going from light to dark, let's do it!...pending others weighing in of course.

[QUOTE=VBCurtis;620318]Gary's idea would swap lavender and orange, so orange is the 160+ color? The new color is a nice choice, looks very good.[/QUOTE]

Yes 120 digits would be lavender and 160 digits dark orange if everyone thinks that's a good idea.

[QUOTE=gd_barnes;620328]Yes 120 digits would be lavender and 160 digits dark orange if everyone thinks that's a good idea.[/QUOTE]

The more purple, the better! (It being my favorite color. :smile:)

Edit: There are no more dark base colors with enough contrast with the links (and the other background colors) to use for 180+ digits. The obvious choice is red, but blue on red doesn't work.

263^24 merges at index=1509 with 36208:i1.

Jean-Luc,

Since you're doing an update, I'll give an update. I have completed all bases down to base 269 to 120 digits. I anticipate having all down to base 250 to 120 digits finished sometime this weekend...3 bases to go.

[QUOTE=gd_barnes;620348]263^24 merges at index=1509 with 36208:i1.[/QUOTE]
Correction :
263^24 merges at index=1509 with 3[COLOR="Red"]8[/COLOR]208:i1.

[QUOTE=gd_barnes;620327]I was somewhat joking about 180 digits. I would suggest not doing that at this point but it's certainly something for several years down the line.[/QUOTE]
I took it very seriously !
That way, we'll be ready in a few years when our machines will allow us to reach 180 figures !
But I don't know how to find a color whose contrast is compatible with the colors of our writings ?
So let's leave this issue aside for the moment.

Complete update of the page done.
Thanks to all for your work.

[B]Added bases : 431, 433, 83328.
Bases reserved for yoyo : 119, 120, 127.
Added exponents 560-600 for base 2 and removed exponents 46-50 for base 5040.[/B]

A next update will be made to change the cell colors until everyone agrees.

Karsten's scripts give the sequences below as being at index 1 :
[CODE] 102 85 172 165
102 92 186 183
105 86 174 174
105 90 182 156
105 94 191 162
119 80 166 157
119 88 183 166
119 94 195 181
120 83 174 163
120 85 178 158
120 90 188 166
120 91 190 153
120 95 198 182
1305184 30 184 180
1352 52 163 154
14264 40 167 159
162 85 189 183
162 86 191 156
162 87 193 166
162 89 197 167
162 90 200 184
1727636 27 169 155
173 83 184 162
18 135 170 164
193 83 188 176
220 80 188 170
229 79 185 181
231 69 164 160
231 76 180 164
26 116 165 157
276 69 169 157
28 113 164 157
31704 38 172 171
31704 39 176 153
34 104 160 154
34 107 164 161
39 106 169 160
392 65 169 166
396 62 162 155
47616 36 169 162
56 91 160 153
56 98 172 154
57 95 167 161
57 100 176 154
60 96 172 163
62 89 160 154
62 96 173 158
6469693230 16 158 156
6469693230 18 178 166
65 89 161 155
65 98 178 153
68 92 169 161
68 97 178 170
68 99 182 157
70 89 165 162
72 98 183 178
74 97 182 169
74 98 184 178
75 96 180 153
76 85 160 154
76 95 179 173
77 89 168 163
77 97 183 175
78 91 173 167
78 94 179 171
78 97 184 170
78 98 186 184
78 99 188 176
80 88 168 151
80 92 176 159
80 95 181 152
84 89 172 162
84 94 182 178
84 100 193 158
85 82 158 154
8589869056 19 189 162
8589869056 20 199 168
86 80 155 150
86 95 184 178
86 99 192 189
87 83 161 153
87 96 186 176
87 100 194 173
88 95 185 167
882 55 163 156
882 59 175 168
888 59 175 159
888 60 178 165
90 95 187 163
91 91 178 169
91 93 182 153
91 95 186 165
91 96 188 163
91 97 190 175
92 97 191 182
92 99 195 151
93 93 183 162
93 99 195 154
94 83 164 157
94 84 166 150
94 91 180 172
94 92 182 170
94 96 190 167
94 97 192 164
94 99 196 164
95 90 178 153
95 94 186 186
95 96 190 175
95 99 196 180
96 86 171 166
96 98 195 170
98 98 196 179
99 82 164 153
99 86 172 170
99 98 196 178
99 99 198 181
996 59 178 164[/CODE]

Ed keeps an updated list of index 1 sequences remaining in the 1st post of that thread.

After removing 5040^49 from his list since the base 5040 max exponent was reduced to 45, both lists will have 117 sequences remaining. So everything looks good.

MediaWiki's Vector skin uses [c]#0645AD[/c] for its unvisited links, which is significantly lighter than the [c]#00FFFF[/c] I've been using for my contrast tests (which itself is darker than what Firefox actually uses by default for links). Switching to that for links would give us more flexibility in choosing background colors, and it would give us a red option (anything lighter than [c]#FFA4A4[/c]).

I have completed testing of new base 83328 all open sequences to >= 120 digits.

Hello,

I need some guestimates from you. What do you think up to which composite size can be computed on 16, 32 64 threads and how long will it run using yafu and going the complete way up to nfs?
Let's assume it should not run longer than 24h.

yoyo

My average time to take a sequence from 100-101 digits to 120 digits with a 110 digit fully ECM'd cofactor is ~4 hours on a Ryzen 3950X 16 cores / 32 threads. The time for each sequence varies wildly from 1 hour to ~20 hours depending on if there is a long flat period or a downdriver run. But that average was developed with over 100 runs of such nature so should be pretty close.

I am running Windows 10 and not Linux so don't have CADO installed so my speed is likely 30-50% slower than such a setup.

Making a broad assumption of comparing the speed of an average size of 100 to 120, which would be 110, and the average size of 120 to 140, which would be 130, and assuming a doubling of time every 5.5 digits, it would take ~12 times longer for a 130 vs. 110 digit test.

So without testing it, I'd roughly guess 4 hours (for 100 to 120 digits) * 12 = 48 hours or 2 days for my setup to run a sequence from 120 to 140 digits and of course 2 days plus 4 hours to run 100 to 140 digits.

So running Windows 10 on 32 cores / 64 threads you might be able to average one day for 120 to 140 digits or one day plus 2 hours for 100 to 140 digits.

Of course those times will vary wildly but at least that gives you a ballpark.

Edit: I read that again. Perhaps you were looking for times for only one test. The above 16 core/32 thread Ryzen takes ~11-12 hours for a 142-digit test so could likely do a C148 in ~1 day. I think that Ed has very detailed averages for composite sizes > 150 digits but his setup I think has > 100 cores. Those averages are for NFS only. Including ECM time, you can add ~10-15% to them.

On a Ryzen 5950X using CADO, I can factor a C156 in 24hr.
I think yafu/ggnfs is in the vicinity of 20-25% slower, around 2 digits.
So, a C154 should be a 24hr job on Yafu with this 16-core CPU.

I have no Intel CPUs more modern than Haswell 2013; those cores are about half the speed of the Ryzen-5000 series, so 16 cores of Haswell might factor C148-C149 in 24hr.

In yafu@home, where I run the aliquot sequences, I hand out single composites to be factored with yafu to volunteers. Based on composite size I require that the system has at least x threads:
>=C140, 32 threads
>=C135, 16 threads
>=C130, 8 threads
>=C125, 4 threads
below, 2 threads.


In the past I thought, that the 32 thread requirement is to hard. But there are some systems, not many, which computes such composites.

Now, I see volunteer systems, which have up to 256 threads.

So I'm thinking about to run composites >=C150 on at least 64 threads.

yoyo

[QUOTE=yoyo;620501]In yafu@home, where I run the aliquot sequences, I hand out single composites to be factored with yafu to volunteers. Based on composite size I require that the system has at least x threads:
>=C140, 32 threads
>=C135, 16 threads
>=C130, 8 threads
>=C125, 4 threads
below, 2 threads.

In the past I thought, that the 32 thread requirement is to hard. But there are some systems, not many, which computes such composites.

Now, I see volunteer systems, which have up to 256 threads.

So I'm thinking about to run composites >=C150 on at least 64 threads.

yoyo[/QUOTE]

Ryzen systems with 16 cores/32 threads have been fairly popular among DC folks in recent years. So you should be able to get quite a bit of work done by systems with 32 threads.

It looks like you're doubling the number of threads every 5 digits. Would you want to do 64 threads for >= 145 digits and 128 threads for >= 150 digits?

Yes, I double threads every 5 digits, because runtime roughly doubles with additional 5 digits.
Currently I run up to C149 on 32 threads.
The described setup was done in 2016. In the meantime also single thread performance has increased.
Maybe I should also increase composite size for each level.

257^22 terminates !

I think I came up with a solution to the issue of including a separate category for main project sequences that may satisfy Jean-Luc's concerns about it being a non-permanent or arbitrary set. Create a "Main Project" category including the bases [i]n[/i] < 3M, where the sequence starting with [i]n[/i] has ever reached [I]i[/I] digits (perhaps [I]i[/I]=100), regardless of whether that sequence has been terminated, merged, or is still open. This set cannot shrink (since we don't eliminate anything when it terminates or merges, and a sequence only needs to reach [I]i[/I] digits once to qualify) and can only expand (if the main project expands its range).

251^28 terminates !

I have completed testing of all bases > 250 all open sequences to >= 120 digits.

For this cycle, completed were bases in the 250 to 300 range. This included testing of bases 251, 257, 263, 269, 271, 277, 281, 283, and 293.

Only bases 251, 257, 263, and 269 still need to be updated.

This was an excellent range. It had 3 terminations and 1 merge with one of the terminations a cycle. :-)

Work continues backwards by base for bases 250 to 200. There are 7 bases in this range with sequences at < 120 digits.

I have received permission from Suika to work on his reserved base 233.

Sequences disposed of with this effort so far:
Terminations:
251^28
257^22
283^20 (cycle)
359^14
359^18
828^19
14536^19
Merges:
263^24
317^8
373^44

Base 443 can be added at the next update.

239^20 terminates

I have posted a test with the new cell colors.
Please look at the bases 2, 3, 77 and 88 on the page and then give me your feedback.
I will do a complete update again : tell me if these new colors are suitable ?

[QUOTE=garambois;621033]I have posted a test with the new cell colors.
Please look at the bases 2, 3, 77 and 88 on the page and then give me your feedback.
I will do a complete update again : tell me if these new colors are suitable ?[/QUOTE]

The light purple for 120 digits is not working.

[QUOTE=gd_barnes;621036]The light purple for 120 digits is not working.[/QUOTE]
I really don't understand what's going on
On 2 of my computers I see the purple and on one I don't see it if I look at the page online, while if I look at the page locally I see the purple !
I don't know how to fix the problem for the moment ?

I see this for base 77:
[ATTACH]27844[/ATTACH]

The CSS for the colour as "co-pu" is set correctly for 120 to 140 digits and used in the table here.

I see the same thing, except on a computer where the cells that should be purple are white !

The light purple shows correctly only on my AMD Ryzen 3950X 16-thread/32-core. It does not show up on any of my 5 main Intel machines: Four 8-core/16-thread I7-10700's and one 8-core/8-thread I7-9700.

I hit refresh several times on all of them.

All are running Windows 10 with a Firefox browser.

Very strange.

Try saving the page on a system where it looks purple and on a system where it looks white. Then compare the page as saved on each system and all the associated files.

If you can't see any difference try loading the saved page on each system, then copying the saved page etc to another dir on the other system and loading it there.

HTH.

You all tried Ctrl+Shift+R, right? Caching is real, and it's a real pain sometimes.

The purple came out lighter than I was expecting. It's a little hard to distinguish. I'd adjust it to #DBF or #DAF (both have allowable contrast).

1727636^28 terminates

Update 13^68 (160 digits),13^42 (149 digits), 13^48, 13^122, 13^64 (all 140+ digits).

Base 449 can be added at the next update.

[QUOTE=Happy5214;621086]You all tried Ctrl+Shift+R, right? Caching is real, and it's a real pain sometimes.

The purple came out lighter than I was expecting. It's a little hard to distinguish. I'd adjust it to #DBF or #DAF (both have allowable contrast).[/QUOTE]

That works.

Weird. To get rid of cached pages, I always hit refresh and it's never failed to update them in the past for me. I don't even know what Ctrl+Shift+R is doing. Regardless, that did the trick.

I am fine with how light the purple is but I feel like it would be OK to darken it a bit.

[QUOTE=RichD;621108]Base 449 can be added at the next update.[/QUOTE]Of note: 449^11 ends in a cycle - (perfect number 6).

[QUOTE=Happy5214;621086]
The purple came out lighter than I was expecting. It's a little hard to distinguish. I'd adjust it to #DBF or #DAF (both have allowable contrast).[/QUOTE]
OK, I tried Karsten's proposal : #D8B1D4.
Let me know if it suits you ?

Just for information, following [URL="https://www.mersenneforum.org/showpost.php?p=617134&postcount=2053"]our discussion on the usefulness of entering certain sequences from this project in the OEIS[/URL], there are finally 3 that have been proposed and validated.

The administrators did not like the short sequences proposed and retained only two of them :
[URL="https://oeis.org/A358239"]https://oeis.org/A358239[/URL]
and
[URL="https://oeis.org/A358266"]https://oeis.org/A358266[/URL]

But finally, they were seduced by another sequence that they then added themselves :
[URL="https://oeis.org/A358415"]https://oeis.org/A358415[/URL]
I should mention that Michel Marcus contacted me before proposing this last sequence to the OEIS.

There could still be many others to propose, similar to this last one : those generated by all our bases which are doubles of squares.
But these other sequences to eventually offer were less popular !

[QUOTE=garambois;621140]OK, I tried Karsten's proposal : #D8B1D4.
Let me know if it suits you ?[/QUOTE]

Looks good!

I have completed testing of new base 443 all open sequences to >= 120 digits.

Taking 385^62 for a spin

I have completed testing of new base 449 all open sequences to >= 120 digits.

Complete update of the page done.
Thanks to all for your work.

[B]Added bases : 443, 449.
New cell colors for all bases ![/B]

There are colors on the page to celebrate the passage to the year 2023 !

Thanks, Jean-Luc! Looks great.
Happy New Year!

All looks great, Jean-Luc. Very colorful! :-)

[QUOTE=VBCurtis;619706]Please leave base 13 to me, still. I'm taking the sequences to 160 digits rather than 140, but I am actively working on multiple sequences in the base.[/QUOTE]

Jean-Luc: Reminder to show base 13 as reserved by VBC for sequences < 160 digits.

[QUOTE=VBCurtis;621105]Update 13^68 (160 digits),13^42 (149 digits), 13^48, 13^122, 13^64 (all 140+ digits).[/QUOTE]

Curtis: 13^68 is still at 146 digits in the FactorDB.

[QUOTE=gd_barnes;621317]
Jean-Luc: Reminder to show base 13 as reserved by VBC for sequences < 160 digits.
[/QUOTE]
Sorry for this oversight : it is now rectified.

Curtis, I still think you're going to achieve quite a computational feat if you manage to color all the cells for the base 13 orange.
Anyway, I know you didn't announce a date, but I don't think it can be done in the year 2023 : 365 days is not enough !
;-)

[QUOTE=gd_barnes;621317]Curtis: 13^68 is still at 146 digits in the FactorDB.[/QUOTE]

Fixed!

Also, update 13^120 (145 digits) and 13^80 (146 digits).

Jean-Luc-
I'm not sure I could complete this task in 2023 either. I think doing so would require most of my resources for the entire year, and I'm not prepared to do that. I will attempt to push one sequence per week to 160+ for the short term, and see how it goes.

I've used this project over the years to test parameter selections for CADO-NFS, and those tests often required a range of composite sizes to factor. That's why I left some sequences small and others got pushed to 160+. Pushing everything to 160 runs counter to my main interest in improving CADO performance, but I'll give it a go for a few weeks and see how far I get.

Of course Curtis, that was a joke !
I know that this work represents a huge amount of calculations.
However, I think it's great to use the n^i project as a resource to find cofactors of the expected size to refine the CADO-NFS parameters.
You kill two birds with one stone.
Thanks for all the hard work !

When I see the amount of points that the yafu project has been producing on BOINC for the last few weeks, I think that the main project may well be expanded to 4 or 5 million (instead of 3 million) during this year 2023.
Unless this increase in contributor activity is due to a raid and therefore only temporary.
The activity is 10 times higher than normal and this is probably why yoyo has reserved so many sequences from the n^i project : the main project no longer provides enough sequences with small co-factors.

It's been a busy last couple of days, so I forgot to check the colors, but the new purple looks good. I don't know if Karsten is checking the contrasts as well, but it just barely passes at a 4.56:1 ratio (the requirement for Level AA is 4.5:1).

Base 457 can be added at the next update.

I have completed testing of new base 457 all open sequences to >= 120 digits.

Rich found a 6-digit cycle for 457^20. :-)

[QUOTE=gd_barnes;621751]
Rich found a 6-digit cycle for 457^20. :-)[/QUOTE]
Indeed, this is not ordinary !
We have already had two other sequences that ended with 6-digit C2 cycles : 257^8 and 65^66, but the cycles are all three different !
Congrats Rich !

I have completed testing of all bases >= 200 all open sequences to >= 120 digits.

For this cycle, completed were bases in the 200 to 249 range. This included testing of bases 210, 223, 227, 229, 233, 239, and 241.

Only bases 210, 223, 227, and 229 still need to be updated.

Work continues backwards by base for bases 199 to 150. There are 11 bases in this range with sequences at < 120 digits.

Yoyo informed me that they are no longer working on base 2. I had asked him about it when I saw no remaining reservations on either of their lists.

I'll do some work on base 2. First I'll ECM everything to t35 on one machine. If there are splits, I'll only work on cofactors C<110. If there are a lot of splits I'll extend that to t40 and C<131 and add some more resources.

With 39 sequences remaining on a double-square base, which is 3 times more trivial sequences than any other base (13 remaining on base 162 is current 2nd highest), I'm hoping to reduce that by a few. :-)

Wow !
The calculations of the unfinished sequences of base 2 are scary when you look at the number of digits of the terms.
I don't know which sequences you will manage to finish : good luck.

[QUOTE=garambois;621925]Wow !
The calculations of the unfinished sequences of base 2 are scary when you look at the number of digits of the terms.
I don't know which sequences you will manage to finish : good luck.[/QUOTE]

By doing the t35 work and splitting any remaining cofactors < 110 digits on all open exponents, I'm effectively doing an initialization process to see where things stand. That only took a few hours so I'm done with that. There were many splits so it appears that few or none of them had any ECM done at all on the latest index. So I'm continuing phase 2: ECM to t40 and split remaining cofactors <= 130 digits on all open exponents.

There are almost always some terminations with the initialization process. It's just a matter of how many. For sequences starting in the ~170-180 digit range, I'm hoping for ~10% so maybe anywhere from 2 to 6 out of the 39 remaining. I already see at least 2 that I can likely terminate myself.

Page updated.
Many thanks to all for your work.

[B]Added base : 457.
Updated bases : 2, 13, 210, 223, 227, 229, 269, 283, 337, 401.
Base 2 reserved for GDB.
[/B]

Base 461 can be added at the next update.

[QUOTE=RichD;622047]Base 461 can be added at the next update.[/QUOTE]461^9:i67 merges with 3876:i5

Thank you very much !
The base will be added in the next update.

I only have a few remaining sequences left that I'm working on for base 2. I'm still working on:
2^560, 571, 574, 576, 578, 579, 593 & 594.

All of the rest are released. All cofactors are > 140 digits and have been ECM'd to t40.

I may run additional ECM on 2^595 and 2^597 in the near future but that is all. They both have very large smallest factors > 2e6.

Great !
Let me know when you finish work on base 2.
Then I may be able to break either sequence myself if I have access to a 64C/128T machine for a few days during February.
But I will try my luck with a sequence where the factor 3 does not appear ;-).

Good luck for 2^595 and 2^597 !
Indeed, the size of the terms can go down very quickly for this two sequences...

I have completed testing of new base 461 all open sequences to >= 120 digits.

Page updated.
Many thanks to all for your work.

[B]Added bases : 461, 295488.
Updated bases : 2, 13, 19, 29, 46, 57, 88, 91, 283, 337, 457.
Non-trivial sequence terminated : 88^43.[/B]

I have completed testing of new base 295488 all open sequences to >= 120 digits.

Per post #2209, all of base 2 can be released except for the following:

2^560, 571, 574, 576, 578, 579, 593, & 594

Also, 2^579 was terminated by me and 2^581 was terminated ~4 years ago anonymously.

Thank you very much Gary.
Don't worry about the reservations for Base 2, I'll take care of that soon.

Base 463 can be added at the next update.

Many thanks Rich !

463^49 and 463^59 terminated

I have completed testing of new base 463 all open sequences to >= 120 digits.

Rich terminated 463^32 in a 2-term cycle of 2620, 2924 that appears to be new for this project.

Thanks to Karsten and Gary.
And congrats to Rich : This will be our 89th sequence that will end on a cycle in this project.

Releasing base 2.

I was able to get 5 terminations as reported in the other thread.

All remaining cofactors are C>=142 and have been ECM'd to t40.

All of the even exponents >= 560 start out with a factor 3 and still have a factor 3 with one exception: 2^594. It dropped the 3 on index 2 and ended up fairly easy to terminate. All other even and many odd exponents will be tough.

34 open sequences remain. Plenty of work for the large resourced folks.

I've made a suggestion to include data files of different types for downloading, so everybody interested in this project do not have to download all data from FactorDB and finding easily the needed information in one file.

The main page will show like this:
[ATTACH]27944[/ATTACH]

Currently there're 6 types of files to download:
- a list of all open sequences
- as example all open seqs where base div 3 and n div 2
- all open seqs with a downdriver (only a "2" in last index)
- all open seqs where only index 1 exists
- all open seqs without a "2" in the last index
- all open seqs with same parity of base and index

All type are available in 3 sorted formats:
- sorted by base ascending
- sorted by length of last index asc.
- sorted by length of last unfactored part asc.

There's also a date in the first line showing the last update.

Examples:
[ATTACH]27945[/ATTACH] [ATTACH]27946[/ATTACH] [ATTACH]27947[/ATTACH]

These file are from my local data so not a current status.

Any suggestions?
Are there any other needed types?
I've also made a file for all found cycles so far.

Those files are created in a few seconds after an update is done by JL.
Implementing starts after suggestions are done.

Base 467 can be added at the next update.

[QUOTE=kar_bon;623104]Any suggestions?
Are there any other needed types?
I've also made a file for all found cycles so far.

Those files are created in a few seconds after an update is done by JL.
Implementing starts after suggestions are done.[/QUOTE]

Would it be possible to add a "current reservation" column? This could be used by a semi-automated script to queue up work from some of the more promising unreserved sequences.

I have completed testing of new base 467 all open sequences to >= 120 digits.

Page updated.
Many thanks to all for your work.

[B]Added bases : 463, 467, 177792.
Some updated sequences.[/B]

I'm taking the 2^597 sequence for myself : a madness, but in 2 or 3 weeks, I'll have a 64C/128T computer for a few days and I'll be happy to try out this monstrous sequence for myself !

@ all :
Please don't forget to reply to [URL="https://www.mersenneforum.org/showpost.php?p=623104&postcount=2221"]Karsten's post #2221[/URL].
He is currently brainstorming additional new possibilities to extract data and present it on the project page.

@ Happy:
Your request is under review.
We'll let you know if it's possible to add what you're asking for to the page.

I have completed testing of new base 177792 all open sequences to >= 120 digits.

Base 295488 also needs to be updated per my post 2213.

13^116 terminates.

[QUOTE=VBCurtis;623292]13^116 terminates.[/QUOTE]

Congrats! After reaching 136 digits too. :-)

Congrats Curtis, one more non-trivial ending termination !

Sorry, I forgot to update the bases 13 and 295488.
Don't worry, I will update these two bases during the next weekend.

13^28 has reached 165 digits with a C160.
I'm presently pushing sequences to 160+, so my updates will be a bit more sparse.