I can definitely provide Python feedback, it is my most fluent (programming) language.

Is

[CODE]
13 C185_145_43 XYYXF SNFS (236.85)[B] 32 [/B][/CODE]correct on the 14e queue?

I've also reserved C204_126_71 and C224_139_50 for 14e. Hope they'll go :)

[b]fivemack[/b]: yes, I will put them on when I have access to my XYYXF-ing script again

[b]fivemack 4/7 0945[/b]: they are queued now

Thanks Tom for taking care of the grid :smile:
I could have spent some time on the code this week-end, but the HDD of one of the computers started producing SMART errors about a handful of permanently uncorrectable sectors for read. I had backups from several months ago, and these errors are not necessarily fatal in the short term - but still, time to swap the HDD...

Amusingly, the smaller, slower and older PATA disk to which I copied a subset of the damaged SATA disk's data contains a near-complete copy of [i]the original RSALS datasets[/i] :smile:
I had completely forgotten about my copy of these datasets. Judging by the files' sizes and names (indicating the ranges), only the first one (TI-84+/84+SE OS key) and the last one (TI-Z80 & TI-68k timestamp key) are incomplete; the latter because my last synchronization didn't occur late enough in September 2009, and the former because sieving was shared between RSALS and individual contributors.

[QUOTE=pinhodecarlos;437367]Is

[CODE]
13 C185_145_43 XYYXF SNFS (236.85)[B] 32 [/B][/CODE]correct on the 14e queue?[/QUOTE]

Yes, I think so; the yield was rather low for lp=31.

If you need some more for the queues, I have a C188 for Home Prime 2 #4496 at index 298. It's nearly finished with a full t55 and has ~1500 curves at t60. If that will suffice, the polynomial is below:

[CODE]expecting poly E from 2.63e-014 to > 3.03e-014 (combined = 2.716e-014)
N 44597900206566944439947932697039613743150116362430753874688185035481133223487816079148414705239978535462694585937895336845024743029953020572500758018545144441759006034478385848403320671021
SKEW 13764574.45
R0 -1256775421329840122548997623542019419
R1 60355472607759799
A0 3235778529368224584941973553338963804501680
A1 688003445336621511215408621066981114
A2 -333434226907675828219419137603
A3 -32502264497288727834542
A4 2060440573008030
A5 14224140
[/CODE]

I haven't test-sieved it yet.

Please add more 14e and 15e work. Thank you.

I am trial-sieving wombatman's G188 as I type, and it is now on the queue. Hope you've got a post-processor with a week on eight core Xeon or three weeks on Haswell lined up :)

[QUOTE=fivemack;437766]I am trial-sieving wombatman's G188 as I type, and it is now on the queue. Hope you've got a post-processor with a week on eight core Xeon or three weeks on Haswell lined up :)[/QUOTE]

Thanks for doing that. If it's not good, let me know and I'll dig up the next highest polys. :smile:

C178_133_71 GNFS ready for NFS@Home queue
 

[url=http://www.mersenneforum.org/showpost.php?p=437780&postcount=646]RichD found a poly for this GNFS job[/url]. It has survived ECM to t55.

[code]
# C178_133_71
N: 3841555638609121585955208849852215958265892685129760666527325956988824434099468571864347054880461407129910718661394754868659901229138374032476680504468397772382909852918017232799
# expecting poly E from 1.07e-13 to > 1.24e-13
R0: -46515930102250406625446814410322748
R1: 43316651465326921
A0: 1849279295652687185857424396955381160117649451
A1: 50719340386210033066265064569927805197
A2: -906428031886864898595060751181
A3: -13675167978469070379277
A4: 24728155385850
A5: 17640
# skew 206008890.45, size 2.494e-17, alpha -8.934, combined = 1.223e-13 rroots = 5
[/code]

Not sure if this is best sieved by 14e or 15e.

GNFS 178 is definitely within 15e territory. The yield of a GNFS 178 would be horrible with 14e, unless the large prime bounds are cranked too high, but in that area, 15e is more efficient anyway.

Several days ago, Dmitry Domanov (unconnected) wrote me a PM containing:
[quote]Could nfs@home help me factoring c172 @i12542 ali.seq. 933436 ? This number survived t55 and some curves at higher level.
Here is the best poly I've found with yafu:

n: 2941346852293234037517328654886758057999048549008145379580550514492407870929699919597152707733195206817617613421985638944532079569396796440114719338940847931813559428853029
# norm 8.931156e-17 alpha -8.048689 e 2.343e-13 rroots 3
skew: 27604940.35
c0: -4031060637140796363608170537279030358925624
c1: 424893644064022404400841966499163833
c2: 23716582430464123017070864819
c3: -1863780343901469945163
c4: 84850758891400
c5: 729300
Y0: -1321685101408011723565902109264757
Y1: 1435326081554367401
rlim: 63400000
alim: 63400000
mfbr: 62
mfba: 62
lpbr: 31
lpba: 31
rlambda: 2.60
alambda: 2.60

Yafu thinks it is better to run it with 14e siever (I'm not sure about this, biggest number that nfs@home factored with 14e was c170).

yafu -nt switch results with different sievers:

new best estimated total sieving time = 72 days 11h 49m 9s (with 8 threads) 14e
new best estimated total sieving time = 77 days 9h 55m 7s (with 8 threads) 15e[/quote]I'll try to spend some time improving the NFS@Home code base this week-end.

Also, maybe several OddPerfect numbers could be queued ?