[QUOTE=EdH;580567]Done:[code]Thu Jun 10 10:29:57 2021 p57 factor: 131602702254471142369840998682715878213808538243164717269
Thu Jun 10 10:29:57 2021 p68 factor: 14058479411029392739744800321961901720197429606455508685678591243029 [/code]I'll work on line 140 (7, 10) unless I see opposition. . .[/QUOTE]
What a story with c124! Thank you for splitting it!
Line 140 (7, 10) is booked for EdH in the sheet.

Line 99 (4, 9)
 

Three easy SNFS 159/160 composites on line 99 (4, 9) are looking for a good home.
One-by-one booking or three different households are welcome.
4 polys for each will be provided, if necessary.
Please ECM first before processing.

[QUOTE=Max0526;580539]That was a tough corner point and the 90th line done in the project!
Thank you for finishing it, fivemack!

[B]> Not quite sure what to work on next[/B]
Line 99 (4, -9) -- two SNFS jobs got released by thyrex. If you pick one/them up, do you need me to generate 4 SNFS polys for each?[/quote]

OK, line 99 I'll start with the S160. I was briefly a Magma developer in a past life (I'm not sure whether my four-descent code is still in the current version, but I spent a lovely southern-hemisphere winter in Sydney) so I'm happy making my own polynomials :)

[QUOTE=fivemack;580576]OK, line 99 I'll start with the S160. I was briefly a Magma developer in a past life (I'm not sure whether my four-descent code is still in the current version, but I spent a lovely southern-hemisphere winter in Sydney) so I'm happy making my own polynomials :)[/QUOTE]
Sheet is updated for SNFS 160. Thank you!

And I suspect if not your PhD thesis and Magma code, this current paper would probably never be written in the first place!
Generators of some of my high-rank elliptic curves could only be found by Magma (not mwrank) and only by implementing four-descent (see my posts at MathOverflow). There are still two Z2xZ6 curves (the topic of this paper) without the last generator.
Magma bug reports is my another hobby. :-)

And yes, they still acknowledge that you "contributed code for performing four-descent, from which the current implementation was adapted."

Having extracted a 22-digit prime factor by 30 thread-hours of SNFS from the c157 on line 99, I'm now running ECM on the other two integers. An even wiser person might have done it the other way round.

The slightly larger remaining integer split entirely by ECM.

Is the C93 from line 99 booked, or not? Just curious. I ECMed it to t31 (no factors), but I didn't want to run SIQS on it if someone else had it reserved.

EDIT: I went ahead and did it, since it wasn't listed under the Composites column, nor was it listed under Booked.

[QUOTE=Stargate38;580620]Is the C93 from line 99 booked, or not? Just curious. I ECMed it to t31 (no factors), but I didn't want to run SIQS on it if someone else had it reserved.

EDIT: I went ahead and did it, since it wasn't listed under the Composites column, nor was it listed under Booked.[/QUOTE]
It was a subproduct of fivemack's ECM: [url]http://factordb.com/index.php?id=1100000002598665029[/url]
I credited both of you.

line 103 c199 factors as:
[CODE]
P76 = 4898445353203033358835060865914937725146210574984871217927446522308970298701
P123 = 760074027570231607044002708206182480265282071391621949720796558088155176608548032700660642236308537183179397780347862834429
[/CODE]

69M raw relations, 57M unique made a 4.4M matrix

Line 140 (7,10): c134 factored, c206 ECM'd to t50, c219 in ECM work. . .

Line 99 done (c139 split as p54 x p85 in 3h20m wall-time on 28-thread Skylake)

Started 28*36 gmp-ecm curves at B1=3e8, default B2 on the C253 from [8,-8].

That's going to be an extremely difficult SNFS job, my hope for finishing that corner is that ECM breaks off a piece big enough to make it a merely very difficult GNFS job.

(quartic SNFS 275-ish, which I think is equivalent to sextic SNFS 315-ish, since the quartic S246 I did a few years back was comparable sieving effort to an S285 sextic - probably about the same amount of work as M1061, so feasible with concerted grid work for the sieving)