[QUOTE=swellman;366399]You weren't joking! It's like drinking from a fire hose.:shock:

Good stuff though. I'll reserve some more this week.[/QUOTE]It's easier for me but even so I'm having to pay serious attention. I'm upstream of all you guys so the major impact on my queue is ensuring that enough ECM pre-testing is being done. Rob Hooft is doing all the heavy crunching (thanks Rob!) but my part is ensuring that he knows how much to do on what and in which order.

My guess is that pretty much all the GCW numbers with SNFS difficulty below 250 digits and all GNFS under 160 digits will be finished this year.

Thanks to everyone who is helping, whether ECM pre-testing, NFS sieving, NFS post-processing or running ECMNET clients.

Paul

GC_6_302 cannot easily be moved back to sieving stage: either I have to create a new entry in the Web interface (but the Web interface does no longer show what the range already sieved for that number was), or Greg needs to connect to the DB and manually change the status of the number...

I'll post process GC_6_302 if that makes things easier.

While it seems additional sieving would help speed up LA for this number, I can throw it on an i7 and grind it out. Probably faster (net) than all the human intervention Lionel describes.

[QUOTE=swellman;366521]While it seems additional sieving would help speed up LA for this number, I can throw it on an i7 and grind it out. Probably faster (net) than all the human intervention Lionel describes.[/QUOTE]

How about having a few people perform additional sieving and feed Mini-Geek if he still has the big .dat file.

I can throw a couple cores beginning tomorrow if someone can define the parameters.

GC_6_302.poly is
[code]n: 4328702185572131219922243105028645058472249163140012398932525775802806127639978382319196735323771365180776850901067568757442949739304109446756885190267242484357
m: 808281277464764060643139600456536293376
deg: 6
c6: 10872
c0: 1
skew: 0.212
type: snfs
rlim: 90000000
alim: 90000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.7
alambda: 2.7[/code]It's unlikely that the range sieved by NFS@Home reached 200M, so I'm pretty sure you can sieve from q=200M - but at such high values, the yield will be lower...

BTW, Sean: I haven't queued C176_118_93 to NFS@Home because the leading coefficient produced by snfspoly is large:
[code]c6: 1643032
c0: 74805201[/code]and as a consequence (it occurred for other OddPefect jobs, for instance), the yield is poor: slightly less than 1 relation per q value from q0=45M to q1=45M+2500, using 31-bit LPs.
If the leading coefficient had been pretty small, a 5th degree polynomial might have done the job... but the leading coefficient produced by snfspoly for degree 5 is even higher than the one for degree 6, so I didn't even bother run sieving tests.

EDIT: hmm, found your e-mail with a different poly again, this time. I'll try it :smile:

[QUOTE=debrouxl;366519]GC_6_302 cannot easily be moved back to sieving stage: [/QUOTE]
Actually it is easier now. I've added a bit more sieving. :smile:

[QUOTE=debrouxl]
BTW, Sean: I haven't queued C176_118_93 to NFS@Home because the leading coefficient produced by snfspoly is large:
[code]c6: 1643032
c0: 74805201[/code]and as a consequence (it occurred for other OddPefect jobs, for instance), the yield is poor: slightly less than 1 relation per q value from q0=45M to q1=45M+2500, using 31-bit LPs.
If the leading coefficient had been pretty small, a 5th degree polynomial might have done the job... but the leading coefficient produced by snfspoly for degree 5 is even higher than the one for degree 6, so I didn't even bother run sieving tests.

EDIT: hmm, found your e-mail with a different poly again, this time. I'll try it :smile:[/QUOTE]

The latest version of Yafu has a nice poly finder for several of the more popular composite forms, including xyyx. It evaluates a lot of polys, selects the top three and runs some test sieving. I could sometimes beat it using hand methods during beta testing, but now it seems pretty solid. Yafu produced the poly given in my message. Hope it gives a better yield than what snfspoly produced.

<break>

Looks like GC_6_302 is still sieving. It's Mini-Geek's if he wants it.

Another data point in the sieving-post processing discussion: GC_11_225 filtered and entered LA with no issues but it will take 281 hours runtime on an i7. Seemed like a lot for a 30 bit job. (Projected completion date is Feb 18.)

By comparison, 6101_59_minus1 only took about 38 hours in LA on an i7.

FWIW.

Taking GW_7_278 (eta Monday morning)

GW_3_493 done
 

[code]
Tue Feb 11 03:30:34 2014 prp63 factor: 474219412211946126250636132859379175735120519441930235382721823
Tue Feb 11 03:30:34 2014 prp74 factor: 54512644954810266463936050260253071511281486423503168096101663043974538979
Tue Feb 11 03:30:34 2014 prp81 factor: 110346700865783842783226509439515387375682318954773407730638286318892359003874047
[/code]

10.4M matrix (target_density 96, because not enough relations to do 112), 102 hours on four threads of i7/2600

GC_10_235 splits as:

[CODE]prp83 factor: 17018236043176407335979492703787844281561871171516165490019071880180094131426675591
prp121 factor: 4054397293024538926351407354713352834805217821458755366711970750544753997448888866960379879416941259547505048002397428701[/CODE]