Polynomial Request Thread
I've been doing polynomial searches for a C210 for 3 months (since Mar 16) on three different video cards (GTX550Ti, GTX570, and GTX580). In the last few weeks I've been really learning how to tweak the command line options to msieve to start getting good results. I started with degree 5 searches and have been doing a lot of degree 6 searches lately. I think the degree 6 searches are probably returning better results due to my better tweaking of the polynomial search options. Here are the best few results I've found so far. Hopefully this can help others know where their best scores for a C210 should be.
[CODE] Degree 5 # norm 1.276810e20 alpha 9.238464 e 9.932e16 rroots 5 skew: 380780879.24 # norm 1.161363e20 alpha 9.018629 e 9.234e16 rroots 5 skew: 609572156.15 # norm 1.358701e20 alpha 6.910857 e 1.038e15 rroots 5 skew: 104279094.33 # norm 1.270759e20 alpha 7.678108 e 9.961e16 rroots 3 skew: 291528643.68 Degree 6 # norm 2.827871e015 alpha 10.512910 e 9.028e016 rroots 2 skew: 1564743.15 # norm 3.242080e015 alpha 9.429823 e 1.024e015 rroots 4 skew: 1013932.94 # norm 3.252680e015 alpha 7.597478 e 1.032e015 rroots 6 skew: 830332.96 # norm 3.384932e015 alpha 7.504910 e 1.054e015 rroots 6 skew: 673235.34 # norm 3.617168e015 alpha 7.884669 e 1.120e015 rroots 6 skew: 741885.74 # norm 3.407911e015 alpha 8.473234 e 1.056e015 rroots 6 skew: 788144.46 # norm 3.211134e015 alpha 9.178180 e 1.016e015 rroots 4 skew: 924161.97 [/CODE] Also, Jason, when was the msieve/CADO E score change/alignment made? All of the above results were with SVN 845 or later. I see in the degree 6 group that the best E score has a pretty low alpha. There are some with slightly worse E that have much better alpha's. Will those poly's tend to be better than the one with the best E? Also, when creating a job file for this C210, should I use the parameters referenced by Batalov in post #43 for the RSAc212: [CODE] rlim: 250000000 alim: 500000000 lpbr: 33 lpba: 33 mfbr: 66 mfba: 96 rlambda: 2.7 alambda: 3.7 [/CODE] Or should I adjust any of those parameters up or down for this C210? 
The comparison between polynomials is meant to be using the Evalue alone; a better alpha just means that the average polynomial value is reduced by more when small primes are divided out of it, but the E value score accounts for that already. If the Evalue is still worse, it means that across the sieving region the average polynomial value is still too large, and sieving is predicted to be slower.
That being said, when the E values are far apart, it doesn't mean that the sieving will be faster by the ratio of the Evalues. Also, when the E values are close between two polynomials you don't necessarily know which one will sieve faster. And of course you can't directly compare degree 5 Evalues with degree 6. The change to the Evalue computation occurred late last year in SVN838 ([url="http://sourceforge.net/p/msieve/code/838/"]link[/url]). 
[QUOTE=VBCurtis;344514]I think we both would benefit from playing with settings and finding polys for a couple of smaller numbers. Perhaps some of the heavy hitters in this forum would like to supply you and I a couple of C155180s to poly search? We can discuss settings, try to learn what stage1 bound produces the largest rate of useful nps hits per hour of gpu time, etc.
I have a c147 in my own queue; I had just done np for 5 days for a poly when this thread began. I tried to apply what we learned last week, and restarted the search. 24 hours of np1 with stage1 set to 2e21 (default is 2.38e22) produced roughly 700MB of hits with a 460M, which will take almost a coreweek to size optimize. This makes me wonder how np manages to do all 3 steps with just one CPU thread without massively stalling the GPU. So, my first tentative guideline is to set stage 1 norm 10x tighter than default when running np1 on its own, and even then the cpu has no chance to keep up. Or does the nps step work with the t threads command? If I understand previous advice, I should not bother to npr more than, say, 500 best nps hits? Curtis[/QUOTE] Here are a few 157digit GNFS candidates: [CODE](181^1031)/((1811)*7417*3386023*1622748672647*767015484026387551*1656939272001358583196903067208809) (877^791)/((8771)*4583*208520387347*96078130292657*103086319456710261705085017633872730943681601) (5591^611)/((55911)*16556099215542617537*743213379283195327995487*11686924821525596917649777) (421^1011)/((4211)*3637*52859291287277*15527015834461272375419*384360771211140230121323*3103491858106402597710257788494888754189303)[/CODE]They are also listed at the [URL="http://oddperfect.org/composites.html"]OPN composites page[/URL]. They have each had a t50. 
And here are a few C155s from the brent tables:
[code]37^148+1: 53256352248508781310601406937700148401433921469238262986221221969535186719520246104398418441069199796933268854865064708804615169745013643006481466447660961 39^158+1: 57251144267448459013407835983100098695823895728185123234566440360247697204733683280958505357854575913997481470550923347918936942495096589838578570989796317 84^1311: 41165489682949123266408283036002947056410598293692637659169409441265128442052082335024569998521857926287112862036984560544046563790581362400293870259353717 [/code] Decent polynomials would be much appreciated. And used within a few weeks. Chris 
Lorgix:
Here is the poly for the first of your C157s. Working on the second one now. [CODE] # norm 3.949172e015 alpha 8.210982 e 2.273e012 rroots 5 skew: 1383524.30 c0: 10405392053173879819844165201642065059 c1: 36925967403223132546442214528403 c2: 58143858551344578567358429 c3: 109070046618529232111 c4: 37237435898622 c5: 7000056 Y0: 931783012256402861904377561482 Y1: 10572282005725577 [/CODE] msieve's "expected" range is 1.99 to 2.29, so this is the best I've found yet compared to the range. 
I'm currently visiting my parents for a few days, but I'll take a whack at those C155 when I get back starting on Sunday night.
Edit: And man, Curtis, you're getting good at finding quality polynomials ;) 
for the last C155; i have
[code]Fri Jul 05 00:42:15 2013 R0: 827616417405609634728088002150 Fri Jul 05 00:42:15 2013 R1: 28187403266123 Fri Jul 05 00:42:15 2013 A0: 5969861234518297522907000759225553806219 Fri Jul 05 00:42:15 2013 A1: 1242828883684993362593839952820816 Fri Jul 05 00:42:15 2013 A2: 314872315331335981141115807 Fri Jul 05 00:42:15 2013 A3: 7334506598186025480 Fri Jul 05 00:42:15 2013 A4: 1345922527272 Fri Jul 05 00:42:15 2013 A5: 106020 Fri Jul 05 00:42:15 2013 skew 10612394.92, size 3.542e015, alpha 7.552, combined = 2.295e012 rroots = 3 [/code] the skew is horrible, i'll try to get it better. 
another one a tad better
[code] Fri Jul 05 03:08:35 2013 R0: 623447711050511546995815433789 Fri Jul 05 03:08:35 2013 R1: 8761390491389 Fri Jul 05 03:08:35 2013 A0: 905530941064703484336217099566456480 Fri Jul 05 03:08:35 2013 A1: 861646222655766816418285571222 Fri Jul 05 03:08:35 2013 A2: 3497899057671750440311749 Fri Jul 05 03:08:35 2013 A3: 1030131356148504116 Fri Jul 05 03:08:35 2013 A4: 152229414212 Fri Jul 05 03:08:35 2013 A5: 437052 Fri Jul 05 03:08:35 2013 skew 1472568.84, size 3.533e015, alpha 4.681, combined = 2.342e012 rroots = 3 [/code] 
I'm running the 1st C155 on the GPU overnight. I'll do the root optimization tomorrow during the day on the top 200 polynomials and report back what I get.

I found a few god one, but 2 in particular might be of interest
[code] Mon Jul 08 11:37:14 2013 Msieve v. 1.51 (SVN 845) Mon Jul 08 11:37:14 2013 random seeds: 1b8e2a80 95a5f588 Mon Jul 08 11:37:14 2013 factoring 41165489682949123266408283036002947056410598293692637659169409441265128442052082335024569998521857926287112862036984560544046563790581362400293870259353717 (155 digits) Mon Jul 08 11:37:15 2013 searching for 15digit factors Mon Jul 08 11:37:16 2013 commencing number field sieve (155digit input) Mon Jul 08 11:37:16 2013 commencing number field sieve polynomial selection Mon Jul 08 11:37:16 2013 polynomial degree: 5 Mon Jul 08 11:37:16 2013 max stage 1 norm: 9.18e+023 Mon Jul 08 11:37:16 2013 max stage 2 norm: 5.99e+021 Mon Jul 08 11:37:16 2013 min Evalue: 2.15e012 Mon Jul 08 11:37:16 2013 poly select deadline: 1051656 Mon Jul 08 11:39:50 2013 polynomial selection complete Mon Jul 08 11:39:50 2013 R0: 1501163178758465311986178676080 Mon Jul 08 11:39:50 2013 R1: 174924457784843 Mon Jul 08 11:39:50 2013 A0: 70988493301319445825160212365935410879 Mon Jul 08 11:39:50 2013 A1: 386946903243104424828373548939059 Mon Jul 08 11:39:50 2013 A2: 334142141498605234086353853 Mon Jul 08 11:39:50 2013 A3: 6353932963613881761 Mon Jul 08 11:39:50 2013 A4: 1028510168554 Mon Jul 08 11:39:50 2013 A5: 5400 Mon Jul 08 11:39:50 2013 skew 16379926.92, size 3.737e015, alpha 7.395, combined = 2.379e012 rroots = 5 Mon Jul 08 11:39:50 2013 elapsed time 00:02:36 Mon Jul 08 11:40:48 2013 Msieve v. 1.51 (SVN 845) Mon Jul 08 11:40:48 2013 random seeds: 7a772be0 46b58b0b Mon Jul 08 11:40:48 2013 factoring 41165489682949123266408283036002947056410598293692637659169409441265128442052082335024569998521857926287112862036984560544046563790581362400293870259353717 (155 digits) Mon Jul 08 11:40:49 2013 searching for 15digit factors Mon Jul 08 11:40:50 2013 commencing number field sieve (155digit input) Mon Jul 08 11:40:50 2013 commencing number field sieve polynomial selection Mon Jul 08 11:40:50 2013 polynomial degree: 5 Mon Jul 08 11:40:50 2013 max stage 1 norm: 9.18e+023 Mon Jul 08 11:40:50 2013 max stage 2 norm: 5.99e+021 Mon Jul 08 11:40:50 2013 min Evalue: 2.15e012 Mon Jul 08 11:40:50 2013 poly select deadline: 1051656 Mon Jul 08 11:43:11 2013 polynomial selection complete Mon Jul 08 11:43:11 2013 R0: 407412222417409604224962008770 Mon Jul 08 11:43:11 2013 R1: 50546045697907 Mon Jul 08 11:43:11 2013 A0: 1286847112018991239507506042869013549 Mon Jul 08 11:43:11 2013 A1: 7383152566924000392587309855332 Mon Jul 08 11:43:11 2013 A2: 12227613193775654000123047 Mon Jul 08 11:43:11 2013 A3: 47036571506094985398 Mon Jul 08 11:43:11 2013 A4: 17650020048104 Mon Jul 08 11:43:11 2013 A5: 3667440 Mon Jul 08 11:43:11 2013 skew 864607.51, size 3.631e015, alpha 6.985, combined = 2.377e012 rroots = 3 Mon Jul 08 11:43:11 2013 elapsed time 00:02:23 [/code] the poly are 5400 174924457784843 1501163185421857259726011744947 3667440 50546045697907 407412222368757771589584073595 
Since my leading coefficient has reached 7e6 I have a dry spell, with very few hit passing the npr stage between 7 and 20e6
( msieve1.50 has a few more, but because the score is surevaluated in 1.50, not in later). Should I widen my stage 1 limits? 
5 days on a 460M for Lorgix' second C157 has produced no strong polys. Here's the best, with msieve suggesting 2.01 to 2.31 as the expected range:
[CODE]# norm 2.916149e015 alpha 7.119644 e 1.883e012 rroots 5 skew: 1639936.64 c0: 8532868550138516311046827336336400640 c1: 70998128199694820805749331912482 c2: 52696319235656576134337513 c3: 75162003432935559781 c4: 19930163724423 c5: 8036784 Y0: 860303108391035434159057424509 Y1: 44662544129823973 [/CODE] I'm starting 39^158+1, the second of Chris' C155s. I'll let it run while I'm in Vegas the next 4 days, and report a poly Saturday for it. Once that's done I'll return to the rest of Lorgix' numbers. In the meantime, could someone beat this poly please? 
Thanks for the polynomials! I haven't gotten around to poly selection on GPU yet, so this saves days of CPUtime.
Hopefully someone will improve on the second one. You seem to know your way around the parameters, so I guess this is what's called 'bad luck'. I might get a used GTX560Ti or something like that (ideas?) so that I have some GPUpower to experiment with. 
You're quite welcome. Now that I know you don't have a GPU, I volunteer to find you at least decent polys for the next few months of your factoring. They may not hit msieve's GPUtarget range every time, but doing your poly selects beats LLRcuda as a good use of my GPU.
Repeated searches in the C155+ region give me some incentive to learn how to testsieve, which leads to fiddling with the knobs as Jason puts it. All useful knowledge, and possibly heading for a beginnerguide midlevel GNFS entry. GPU ideas: Go cheap, just get anything that supports the right flavor of CUDA. Even a lowend current card will be 50100x faster for stage 1, while using fewer watts than a $100+ card. 
The GTX5xx are 2 generation behind. It might be hard to get "new" one. I guess a GTX 650 or 640 (if they are not only for laptop) might work for you.

[QUOTE=VBCurtis;345720]You're quite welcome. Now that I know you don't have a GPU, I volunteer to find you at least decent polys for the next few months of your factoring. They may not hit msieve's GPUtarget range every time, but doing your poly selects beats LLRcuda as a good use of my GPU.
Repeated searches in the C155+ region give me some incentive to learn how to testsieve, which leads to fiddling with the knobs as Jason puts it. All useful knowledge, and possibly heading for a beginnerguide midlevel GNFS entry. GPU ideas: Go cheap, just get anything that supports the right flavor of CUDA. Even a lowend current card will be 50100x faster for stage 1, while using fewer watts than a $100+ card.[/QUOTE] Well, I actually have a CUDAcapable GPU. But it is weak, and has few cores. And it is hooked up to my main screen. There are currently five p^q1GNFScandidates in the range 154156. I could pretest some above 160 as well. I also have my eyes on a HPnumber in the low 160s. So there's no shortage of candidates, if you're up for it. I really should be getting a new GPU some time soon (in a few moths, at least). More powerful ones should be very useful for ECM. Does poly select saturate any GPU? (can it use any number of cores?) Maybe I'll opt for a cheaper one; a GT630 based on GK208 (meaning 28nm) was released fairly recently. Should I look for the latest Compute Capability? (I don't really know the significance of that) [QUOTE=firejuggler;345721]The GTX5xx are 2 generation behind. It might be hard to get "new" one. I guess a GTX 650 or 640 (if they are not only for laptop) might work for you.[/QUOTE] I was under the impression that the Fermi architecture was still very competitive in GPGPU. I'm not sure though. The GTX650 should be close to peak performance/$ (in the sense of MHz*cores/$), in the 600series, and so should be a good choice I suppose. The 6 & 700series use an entirely different architecture than the 4 & 500, so I don't really know how to compare them. Specifically I'd like to know what correction factor I need in order to compare MHz*cores between Fermi and Kepler. In terms of poly select performance (and ECM performance). 
VBcurtis, what msieve version did you use to find that poly? it seems that Msieve150 and below surevaluate the poly score a bit.

1.51, svn 845 (I think). April 2013 download, premade binary. It should be the newer/lower Evalues.
My GPU also drives my main screen, and the only time response has slowed was on the C210 sextic search. I've run cudaLLR for 12 months straight, and now poly select, with no apparent effect on the screen. I suggest you get CUDA drivers installed and test things out if nothing else, you can see how many hits you get overnight on the card. My mobileGPU part isn't all that fast, and still can produce 8 hrs' worth of nps work in just an hour or two. So, just overnight GPU np1 runs might produce more than enough data for stage 2 needs. Yes, I am game for at least a halfdozen candidates after those already posted by you and Chris. 
For now I have one *good* hit , score is equivalent to VBCurtis but skew is a bit lower
[code] Tue Jul 09 02:19:43 2013 factoring 3787388118933512063249259173231597770049112435945032094640277541632460519045009491164974276597271170346757143570242916437315466248541421375702840232794402591 (157 digits) Tue Jul 09 02:37:40 2013 R0: 1063466059487867106617472794654 Tue Jul 09 02:37:40 2013 R1: 64668823176851 Tue Jul 09 02:37:40 2013 A0: 3962907102148251811365883799925121155 Tue Jul 09 02:37:40 2013 A1: 989212107945990307577657150068 Tue Jul 09 02:37:40 2013 A2: 6390045909351316737980130 Tue Jul 09 02:37:40 2013 A3: 9592336224573633921 Tue Jul 09 02:37:40 2013 A4: 5859137926178 Tue Jul 09 02:37:40 2013 A5: 2784336 Tue Jul 09 02:37:40 2013 skew 1408059.13, size 2.287e015, alpha 6.085, combined = 1.833e012 rroots = 3 [/code] 
For the 1st C155 listed, this is the best I've gotten thus far. It's a bit below the expected range, but not by too much:
[CODE] expecting poly E from 2.62e012 to > 3.02e012 R0: 1982277912715175423679197808784 R1: 69837075648803257 A0: 44322257284138334787861242542456972633815 A1: 9286106559194619360096878548752378 A2: 108520072080442627462348267 A3: 10202649139317912268 A4: 61572653402 A5: 1740 skew 45960569.14, size 4.023e015, alpha 7.466, combined = 2.541e012 rroots = 5[/CODE] 
[code]
factoring 3787388118933512063249259173231597770049112435945032094640277541632460519045009491164974276597271170346757143570242916437315466248541421375702840232794402591 (157 digits) R0: 1378574698621825663558022013546 R1: 214052541470369 A0: 175040708004969558266567903993405593325 A1: 220312394373520757850174317763772 A2: 49282988466830844032614321 A3: 25532977516064005444 A4: 3884830113524 A5: 760656 skew 3526801.51, size 2.601e015, alpha 7.664, combined = 1.978e012 rroots = 3 [/code] 
Here is the poly for 39^158+1:
[CODE] # norm 5.644615e015 alpha 7.931357 e 2.775e012 rroots 3 skew: 1813413.83 c0: 26576343119721934097475724487682275175 c1: 58618135712883968651879051388681 c2: 21402685978619238283492841 c3: 24030041819615310289 c4: 13579142843224 c5: 4598160 Y0: 415948918490177005559476926358 Y1: 30809158838486467 [/CODE] I am now working on the third of Chris' numbers. Or was it already done? Edit: Ah, seems post 121 refers to this third number. I'll stop my search now, run npr on the overnight data, and report if I found a better poly. Edit2: Nothing of use. I am now working on the 3rd number from post #85. Firejuggler, the 4th number from post 85 has had no work yet. 
[QUOTE=firejuggler;346204]If anyone need a poly in this range (150170 digit) , ask. Or if I forgot one in this thread, remind me.[/QUOTE]
Would you be willing to give [code] 23847813234751095518553790092375554156554053397317779773831395300907022889988067196688707035368393323174109573706580716877436977083912429179428455659750299481884888866554791173 [/code] a go? It is the 176digit cofactor of iteration 677 in sequence 3270, which is I think still the shortest sequence starting with a number below 10000. If that's too big, [code] 86026587992252713187749194939696412639941777372908947403799022828963200928303537489025731813345034713461276262988371957157619420275286481805832459392273827 [/code] (the 155digit cofactor of 9436.1316) would also be of interest 
I'll give a nudge to the 176. I'll report back in few hours no garantee of a good poly.

I'll take a whack at the 176 as well.

Big is good if I have the sievetime estimates correct, all three of us can spend a few days on this number productively.
I'll start at 23.5M. 
What range do you recommand? 8M? or above, 40M?

I'm running 100M+ (polydegree 5).

I think anything 10M+ will have skew roughly similar. Even though overlapping ranges only duplicates a little bit of work, it's easy enough to search different ranges.
We can report our typical skews for the lists of decent polys to make sure 20m, 100m, and whatever you choose really are similar. 
Sounds like a good idea. It'd be nice to know how the skew varies (or doesn't) for given ranges. Here's my first one so farit's a fair bit under the expected range:
[CODE] expecting poly E from 1.46e013 to > 1.68e013 R0: 2988691192272804298611698595599499 R1: 237161778113747539 A0: 32731363407803097195252649322319485122428800 A1: 3923946321852883713926555500462761080 A2: 1172068129952158854846849214634 A3: 65955053275793992651415 A4: 8394258833127276 A5: 100009980 skew 13540340.13, size 2.166e017, alpha 8.427, combined = 1.085e013 rroots = 5[/CODE] Edit: Here's one with slightly better score and an order of magnitude lower skew: [CODE]polynomial selection complete R0: 2988105935112559387239257538404549 R1: 262138118976309551 A0: 1684154512885205386857910460902575111600 A1: 40913519008928283606564309026397940 A2: 42965292076801711799985554792 A3: 3340385908071805886631 A4: 682953059486718 A5: 100107960 skew 4054135.37, size 2.263e017, alpha 6.468, combined = 1.142e013 rroots = 3[/CODE] 
Skews for coeff = 23M are 712M for alphas in the 6's, 11 to 16M for alpha over 7. Best score after a few hours is 1.24e13 w/skew 8.7M.

Update: Score 1.32e13, skew 7.3M. Since wombatman's skews are lower than mine, I'll add a zero for tomorrow's run after a C152 run for RichD's aliqueit sequence.

For the C176
[code] R0: 2258685475663263250324560136301285 R1: 140428258550291 A0: 802438015828677555679491307924381393152 A1: 36920184606841951622303727157923495 A2: 41481464461097192689035440776 A3: 488488458101203216750 A4: 4075532791202328 A5: 405667080 skew 2987703.90, size 2.744e017, alpha 6.656, combined = 1.281e013 rroots = 5 [/code] 
To clarify my last post, I'm now sieving 84^1311 (the last of the 3 I listed). I meant I'll queue the first of the two firejuggler found for processing. Sorry for the confusion.
Chris PS. Has anyone worked on 39^158+1 (the middle one of the 3 I listed)? wombatman found a poly for 37+148+1 (the first one I listed). PPS. And many thanks again. 
Will work on the fourth number of post 85 once i'm done proccessing the hits on the C176

Chris
See post #123 for the poly for the middle number. Curtis 
I am doing poly search for the C152 from Aliquot sequence 3408:1287.
I'm using my usual settings from this thread: Default stage1 norm, nps stage 2 norm roughly default/18 (1.5e20 in this case). I get my usual 100kb of nps output in 12 hrs, but npr produces ZERO polys, even when I loosen the min e value lower than default (3.5e12 instead of default 3.63e12). Are there numbers where the polys found are just terrible compared to expectations? I just loosened the min value to 3.0e12, and I get plenty of poly output so it's not a software error, far as I can tell. Coeffs for these tests are in the 36M range, which seems pretty standard for a C152. Edit: Should I experiment with stage2 norm for the npr step? 
I think there are still some infelicities in the table of norms and minE; I'm getting ludicrously high yield around 160 digits and, as you mention, very low yields at C152.
For 9096168730717325471174345357545088389800010197483699618393510880224063584308788722339816387794620862849936796290458644418085736533343831602295288484811 (151 digits) I ended up with (at least in October 2011, parameters may be changed now) with 20k polynomials in msieve.dat.p for each 1000A5 range. But running 3936090042216234613709067994268312375269653484027874112960552153626006376667321970650341587753839767751476856325227586616119340003347991887464416435517 (151 digits) last week I got no more than ten polynomials in some such ranges. For 4202701474560599145864668379214403877602720577806362075074321031589277391358279336093140444841799054199486202393045071085680275027063857193327313335405064090859 I got 35k polynomials for each 1000A5 range 
We've sometimes seen input sizes where the chosen bounds are too conservative, in that too many hits get found, but almost never the opposite.
Also, the numerical value of the skew that you find doesn't have very much to do with sieving quality, so it isn't a big deal if you find a poly with large skew. It usually is just an indication that your search is in an early phase, where you get a polynomial with a very good root score that requires really stretching the skew to achieve. 
nothing better in the 400420M range than what I already posted for the C176

for (421^1011)/((4211)*3637*52859291287277*15527015834461272375419*384360771211140230121323*3103491858106402597710257788494888754189303)
I have a flare [code] R0: 3827996057819835127917748724463 R1: 131539370518073 A0: 602715843958817538679066753523087553532960 A1: 45781605633077304430392767759952648 A2: 1068428398276002038958183140 A3: 48864994613567679099 A4: 571757632456 A5: 9180 Mon Jul 15 02:40:31 2013 skew 46132459.25, size 3.041e015, alpha 8.806, combined = 2.126e012 rroots = 5 [/code] skew is horrible; found a second hit @ [code] R0: 1766358190766735704168317054222 R1: 112645411133573 A0: 493231366602757377598300196387454965 A1: 2761322107950780473345799391567 A2: 16280562559665314935321596 A3: 18743805941490767137 A4: 7812064738909 A5: 438840 skew 1418693.51, size 2.267e015, alpha 5.886, combined = 1.806e012 rroots = 5 [/code] Skew is better but score, not so much I will extend search upto a leading coef of 3M 
It's not better than what Curtis got, but I'll include my best so far for posterity and comparison of skews and whatnot:
[CODE]R0: 2985364064788479756004867693430704 R1: 338252966469030421 A0: 850411162568663002775199166333595393602815 A1: 912278472619088502716551535935935096 A2: 30604247888096781733208334160 A3: 36949595121636590255444 A4: 2832475140989925 A5: 100568520 skew 8586463.91, size 2.728e017, alpha 8.174, combined = 1.281e013 rroots = 3[/CODE] 
Each 5digit increase in size takes roughly double the effort to sieve and should have a corresponding increase in polyselect time. This C176, at roughly 20 digits larger than our other searches, deserves ~15x more effort than we have given the other numbers.
I've been putting ~3 days into the 155157s in this thread, which may be why I'm often getting better polys. I will be putting at least a week into my part of the C176 search, more if I/we don't find a "lucky" poly. If the three of us put a week each into it, we have a good chance to find a poly worth sieving with. For this search, I think that's 1.45e13 at minimum. 
(421^1011)/((4211)*3637*52859291287277*15527015834461272375419*384360771211140230121323*3103491858106402597710257788494888754189303) again,
[code] R0: 1379023836637462618160987168271 R1: 117578686639117 A0: 36460967635057249759007362058565617216 A1: 82932889219472424950843244760688 A2: 66710061781474557308819682 A3: 21316592155418774201 A4: 9644497418536 A5: 1513008 skew 2662773.43, size 2.688e015, alpha 7.134, combined = 2.021e012 rroots = 5 [/code] I will resume my search on the C176 
[QUOTE=VBCurtis;346319]Chris
See post #123 for the poly for the middle number. Curtis[/QUOTE] Got it. Sorry for the oversight. And thanks for the poly. I'll wait until I've factored those 3 before I submit any more numbers (unless you are running out of test cases). Chris 
[QUOTE=firejuggler;346204]If anyone need a poly in this range (150170 digit) , ask. Or if I forgot one in this thread, remind me.[/QUOTE]
If this offer still stands, would you mind attempting to find a good poly for this C169? [code]2203286292154236920662074580008136560385550762038571072069284129582298550469011615783387269827436918721335468107066200517568432204890391543672088684775850203864157356993 [/code]It's a cofactor of C169_123_109 from the [URL="http://xyyxf.at.tut.by/status.html"]xyyx project[/URL]. I can reciprocate by running some ECM or other factoring task for you. Thanks. 
C 176 of seq 3270.i677, found a better one, still not very good
[code] Mon Jul 15 19:59:59 2013 R0: 2568057394873298560629759814025187 Mon Jul 15 19:59:59 2013 R1: 439667603047187 Mon Jul 15 19:59:59 2013 A0: 2376484718573209075312622593319346652671680 Mon Jul 15 19:59:59 2013 A1: 766203357705019533635038915567469368 Mon Jul 15 19:59:59 2013 A2: 205162472710480561266546759890 Mon Jul 15 19:59:59 2013 A3: 4007692778132342016203 Mon Jul 15 19:59:59 2013 A4: 523802142731100 Mon Jul 15 19:59:59 2013 A5: 213513300 Mon Jul 15 19:59:59 2013 skew 8257159.93, size 2.875e017, alpha 8.679, combined = 1.327e013 rroots = 3 [/code] now will give a nudge to [code] 86026587992252713187749194939696412639941777372908947403799022828963200928303537489025731813345034713461276262988371957157619420275286481805832459392273827 [/code] (the 155digit cofactor of 9436.1316) Swellman, I'll get you something in the next 48 hours. 
Thanks a lot!

i've got a decent one for 9436.i1316, search continuing
[code] score is supposed to be 2.55e012 to > 2.93e012 R0: 968570173465693155394698061307 R1: 475524413938021 A0: 428389013154971721280710914712321354000 A1: 292799622011886831826018199855838 A2: 9878586190707635075783980 A3: 13948567785977503723 A4: 427349694910 A5: 100920 skew 6966773.42, size 4.361e015, alpha 7.161, combined = 2.665e012 rroots = 5 [/code] 
I'll give the C169 an overnight run too, and then run the c176 while away on another trip wedsun.
No improvement in day 2 of C176 from the 1.32e13 I had in day 1. 
To throw in with Curtis on the C176, I still haven't managed anything better than 1.281e13. Still working on it, though.

Polynomial Request Thread
Far be it for me in all my newbieness to proclaim anything, but given the recent spate of number requests, I thought it might be nice to have a thread devoted to requests for polynomial searches by those of us with free GPUs so the numbers aren't lost in the jumble of a thread.
I don't know who moderates this particular forum (Jason?), but it'd be nice to be able to edit this post past the typical 60 minute limit, if possible. In case the board isn't able to do that without a lot of effort, I'm going to make a google document to store all the requests, those who have announced intentions to search (and what intervals, if that is specified), and perhaps the best poly score provided for a given number. In terms of general ground rules, my thoughts are that they should be something like this: 1) Unless otherwise specified by the person requesting, any number of people may choose to search on a given number. 2) If the factoring of said number leads to any kind of publication or something similar, the person who found the polynomial used must receive appropriate recognition (listed as an author on an article? I would welcome suggestions here). Honestly, I think that covers the best stuffif anybody has any other suggestions, please feel free to comment, and I'll add them. For now, the google doc is located here: [url]https://docs.google.com/spreadsheet/ccc?key=0AlFp2DvBLxsUdEtUMFE0bmk3blRQQlJhS2NkcEF2b0E&usp=sharing[/url] I think it will not be accessible until your email is added. Worse comes to worst, I can email it to you. If you would like to be added, just PM me your address. I do solemnly swear your email will only be used for good! :whistle: 
second one for 9436.i1316
[code] polynomial selection complete R0: 497297792444644756750585103945 R1: 6087136917587 A0: 2669879484961643012363909599431422364 A1: 7170432640162821655875608918240 A2: 5086090535159906315799875 A3: 11125962104135412730 A4: 6115975384434 A5: 2828460 skew 1395299.68, size 4.087e015, alpha 6.778, combined = 2.603e012 rroots = 3 [/code] Now, onto C169_123_109 
Day 1 on the C169 produced 3.315e13. I'll put a second day on it before resuming the C176.

Day 1 for the C169 produced a 3.694e13
[code] R0: 384580347035682112978309208888480 R1: 7069004002408717 A0: 3465513533571190599220783764906879085904469 A1: 1069822016219563236870593762230230147 A2: 66001602968642015370778936319 A3: 270830722426445846387 A4: 30351561461328 A5: 261900 skew 42174313.97, size 1.629e016, alpha 7.922, combined = 3.694e013 rroots =5 [/code] 
Folks, the polynomials will be more easily handled by original requestors/other testers if you'd insert the corresponding "n: ..." lines in them.

a swing and a flare for swellman C169 : I dug around and far above, nothing come remotly close
[code] 2203286292154236920662074580008136560385550762038571072069284129582298550469011615783387269827436918721335468107066200517568432204890391543672088684775850203864157356993 (169 digits) R0: 344517009720320657345668021520609 R1: 870535396513771 A0: 252681583117408750059938913868667397960 A1: 716807602129660819233465802155626 A2: 1024911528196794072738767285 A3: 155515608837130473266 A4: 37852190172270 A5: 453960 skew 5721717.05, size 1.841e016, alpha 6.366, combined = 4.109e013 rroots = 3 [/code] second best is [code] R0: 184867009335706375918336105167641 R1: 4516317103847593 A0: 1644779338364768599262639379010622162880 A1: 5959645159071631098948779011562416 A2: 497653412302780065536297780 A3: 1301468255968671143028 A4: 6112424626753 A5: 10204080 skew 4578349.68, size 1.489e016, alpha 6.645, combined = 3.600e013 rroots = 5 [/code] 
That's fantastic. The e score exceeds expectations, and GPU found it so fast.:smile: The speed is breathtaking.
I'll run test sieving tonight, and will start in earnest in a week or two once another job finishes. If anyone thinks it helpful, I'll post some details in the large GNFS advice thread. Many thanks to firejuggler and VBCurtis (and anyone else I missed) for the GPU poly effort. 
Please do post your parameters in the advice thread. A second day on your number found nothing. 4.11 is amazing!

Wow! Very well done! I too would be interested in your parameters. I'm still running the C176, but I haven't gotten any scores better than 1.28e13 (best is 1.32e13 with expected of at least 1.46e13).

Just wanted to note that with the latest SVN (922), the escore calculation has been revised, and the C176 now has an expected score of
[CODE]expecting poly E from 1.32e013 to > 1.51e013[/CODE] so Curtis, your best poly so far is actually now in the range. 
That is a good news. I didn't find anything better than VBCurtis so far. I'll withdraw from the C176 run if I find nothing in the next few hours.

The score* now should be as easy to achieve as it was before the r838 rational alpha correction. That is the idea (the units were corrected for that). In the interim versions (r838r920), one would try too hard to reach the invisible line.
___________ *The 'expected' score is just a guideline based on the work of thousands of invisible peers and the scores that they achieved before switching to sieving (that is for welltrodden gnfs sizes, and then this estimate is extrapolated over ranges where very few people went before). If minimizing the total gnfs project time was not the goal, one can find exceptional polys. (In a way, searching for gnfs polynomials could be compared to bitcoin mining: the longer you mine, the more value you may find.) For the GPUassisted binary, the invisible line is moved up as if the input number size was 'one digit shorter' (each decimal digit of the input size roughly corresponds to 1.15 times lower E value). 
Thanks for the explanation, Batalov.

[QUOTE=Batalov;346655]The score... <snip>[/QUOTE]
:goodposting: 
I ran 160hr of GPU time on the c176, finding nothing better than I found the first 12 hr. I'll give it another day or two on previous runs, my experience is that one or two polys are well above the rest, while on this run I have had 1.32, 1.30, 1.29, 1.28 twice, etc.
[CODE] n: 23847813234751095518553790092375554156554053397317779773831395300907022889988067196688707035368393323174109573706580716877436977083912429179428455659750299481884888866554791173 # norm 3.498911e017 alpha 7.554399 e 1.321e013 rroots 5 skew: 7302723.20 c0: 585974218494806930768644061943126986617800 c1: 123674309334161409004434007196790770 c2: 86457601091391410858185957207 c3: 12290247685982271688258 c4: 2200504487556284 c5: 23604840 Y0: 3989233893948153787648433928935443 Y1: 68135514398968631 [/CODE] 
A Challenge
Aliquot Sequence 4788 sits at index 5154 with a c173 remaining. The best poly found so far is posted at: [URL]http://mersenneforum.org/showpost.php?p=337945&postcount=2102[/URL].
This is a very, very low request but can this poly be bettered? I believe the leading coefficient has been tried through 800K. 
I will try.

Another poly for Tom's C176:
[CODE] n: 23847813234751095518553790092375554156554053397317779773831395300907022889988067196688707035368393323174109573706580716877436977083912429179428455659750299481884888866554791173 # norm 3.445278e017 alpha 6.820795 e 1.321e013 rroots 5 skew: 3088331.89 c0: 498014898833129675206187724146860356135 c1: 24249301299856929460089682902161763 c2: 34320331326371745034488026956 c3: 7376626463852947241062 c4: 3051637511514764 c5: 214785480 Y0: 2565008026979220326617490926563632 Y1: 186995647017448237 [/CODE] If I understand things correctly, for a job this big it's worth trialsieving the polys within, say, 2% of the best score? I am still running the GPU on this in hopes of score 1.40; if I give up, I'll post the 1.30 for trialsieving purposes also. 
Stupid question about trialsieving:
Is that essentially seeing how many relations/sec one gets with a given polynomial? 
[QUOTE=wombatman;347260]Stupid question about trialsieving:
Is that essentially seeing how many relations/sec one gets with a given polynomial?[/QUOTE] Yes, as well as relations/special_q. ETA: See [url=http://www.mersenneforum.org/showpost.php?p=347141&postcount=56]this thread[/url] for a discussion on sieving estimates. 
Trial sieving is supposed to try minimizing the time that sieving needs to complete. That means picking the size and number of large primes, estimating the number of relations that would be needed from that, then sieving a few widely separated Q values (say 1/1000 of the complete job) and computing the estimated total sieving time giving the relations/sec found across each range.
It amazes me that folks here have the discipline to manage fullscale trial sieving for any job. I don't think I could do it. 
Man, you're not kidding. Might be interesting to play around with, but at this point, I think I'm limited more by not having a cluster (quad core laptop processor! woooooo!) to use for the sieving rather than tweaking the parameters for optimization.

I, too, have an i7 laptop as my factoring tool. You're mostly right about trialsieving mattering less for us if, say, 3 humanhours spent on optimizing parameters can save 10% of a job's sieve length, we'd have to be running a very lengthy job (or REALLY treasure our CPU time vs our human time) for the trial time to be worthwhile.
But as one moves up into GNFS150s, the prospect of 10% saved can mean days of CPU time; not to say we'll automatically find 10% efficiency... Further, it strikes me that one ought to learn which knobs to turn to attempt to optimize when the cost of a mistaken "optimization" is days rather than weeks. When I do get around to tackling a GNFS150, I plan to try just this even though best parameters are well known (?)in the 150s. Do enough people use the factmsieve script for 150+ factorizations that we (I volunteer) should update the parameters files? 
[QUOTE=wombatman;347280]Man, you're not kidding. Might be interesting to play around with, but at this point, I think I'm limited more by not having a cluster (quad core laptop processor! woooooo!) to use for the sieving rather than tweaking the parameters for optimization.[/QUOTE]
I've done over 40 factorizations with the same rig. Depending on memory, you're good for GNFS into the 160s, equivalent SNFS. Don't get too wrapped up in the optimization  for factorizations of that size, the net sieving time difference between a perfect and a suboptimal poly is only a few days. Personally I don't worry if a factorization takes say 26 days instead of a theoretical optimal of 23 days. Start hunting big game (e.g. GNFS 190s) and things are much different. [url=http://www.mersenneforum.org/showthread.php?t=15744]Sieving jobs can take CPUcenturies[/url]. :max: All IMHO of course. 
[QUOTE=VBCurtis;347285]I, too, have an i7 laptop as my factoring tool. You're mostly right about trialsieving mattering less for us if, say, 3 humanhours spent on optimizing parameters can save 10% of a job's sieve length, we'd have to be running a very lengthy job (or REALLY treasure our CPU time vs our human time) for the trial time to be worthwhile.
But as one moves up into GNFS150s, the prospect of 10% saved can mean days of CPU time; not to say we'll automatically find 10% efficiency... Further, it strikes me that one ought to learn which knobs to turn to attempt to optimize when the cost of a mistaken "optimization" is days rather than weeks. When I do get around to tackling a GNFS150, I plan to try just this even though best parameters are well known (?)in the 150s. Do enough people use the factmsieve script for 150+ factorizations that we (I volunteer) should update the parameters files?[/QUOTE] I use YAFU exclusively and with great success. But its automated GNFS parameter table tops out at 155, as that was considered the bleeding edge when YAFU was first created. Manual intervention is required when factoring larger GNFS composites. While I find this manual process fun and educational, expanding the parameter base might be beneficial. 
[QUOTE=swellman;347286]I've done over 40 factorizations with the same rig. Depending on memory, you're good for GNFS into the 160s, equivalent SNFS. Don't get too wrapped up in the optimization  for factorizations of that size, the net sieving time difference between a perfect and a suboptimal poly is only a few days. Personally I don't worry if a factorization takes say 26 days instead of a theoretical optimal of 23 days.
Start hunting big game (e.g. GNFS 190s) and things are much different. [url=http://www.mersenneforum.org/showthread.php?t=15744]Sieving jobs can take CPUcenturies[/url]. :max: All IMHO of course.[/QUOTE] I'm with you. I've worked on various sizes of numbers. I don't recall the largest I've completed starttofinish, but I think it was high C130s or low C140s. I have a C157, C158, and C159 I'm working on now. I suppose if I were to do a big number, I would just post the poly on here and ask for help. Thanks for all the information re: sieving time of larger numbers. I hope that one day soon we'll be able to sieve using a CUDAbased system. That would be fantastic. 
RichD, the best I have right now doesn't come close to yours, except maybe for the skew.
[code] R0: 841266904723342746233131420252313 R1: 855195155267364017 A0: 30166472851843691039847519848973738784800 A1: 164214468637061679052505169668233520 A2: 15353639313287889495535261470 A3: 9108415526487500533233 A4: 205906441056020 A5: 41020812 skew 7546972.79, size 6.501e017, alpha 7.824, combined = 2.190e013 rroots = 5[/code] 
Here are my 3rd and 4th best polys for Tom's C176:
[CODE]n: 23847813234751095518553790092375554156554053397317779773831395300907022889988067196688707035368393323174109573706580716877436977083912429179428455659750299481884888866554791173 # norm 3.325425e017 alpha 7.877752 e 1.295e013 rroots 3 skew: 5951640.57 c0: 258966513599481929079497470679516666534935 c1: 285698172063866150512027099539634511 c2: 36140358534479527549329501741 c3: 23721865971444823325851 c4: 2071207813249694 c5: 189059640 Y0: 2631297462869838988968661000353606 Y1: 203813686529856847 # norm 3.367613e017 alpha 7.168929 e 1.301e013 rroots 5 skew: 3566066.45 c0: 12846994264038559909666735853053878530515 c1: 35740142054062710926827563223220239 c2: 57581223637699248717129312831 c3: 8030589997871536186225 c4: 4361415500113574 c5: 191086896 Y0: 2625690488756168583101379509747664 Y1: 279402161496116951 [/CODE] This ends my search, after 12 days of GPU time. There are two 1.32e13 polys posted earlier in this thread, so I've posted my four best. 
c155 Poly Needed
Aliquot Sequence 3408:i1311 has a c155 that will be completing the ECM requirements soon. Requesting a nice GNFS poly. :smile:
The last term of the sequence is [URL="http://factordb.com/sequences.php?se=1&aq=3408&action=last&fr=0&to=100"]here[/URL]. The c155 is located [URL="http://factordb.com/index.php?id=1100000000628669496"]here[/URL]. 
I'll try and get a run started tonight and let it go for a few days.

I'm using stage2norm = 3e20. Starting at coeff 27.5M.
I think a c155 deserves 45 GPUdays among us. 
I'll use the same stage 2 norm and run 16M and up (to no higher than 27.5M).

I'll play a bit too.

got a big flare
[code] R0: 752215439962598490152595371493 R1: 3043019462110933 A0: 16684657176007582166169914019047758768 A1: 17394275022872707256456451601892 A2: 2404909861959159815942388 A3: 2404339594478673317 A4: 207481588574 A5: 46956 skew 4182639.36, size 5.869e015, alpha 6.105, combined = 3.230e012 rroots = 5 [/code] 
What's the Escore range for it? (I'm at work, my msieve is running at home)

Expecting poly E from 2.88e012 to > 3.31e012
And sorry for releasing my poly so early, it's just that... it's a very good one. 
Nice work!

Skew is about 4 times the polys I'm finding. Nice score, it'll likely be the best we find.
Why do you start with A5=1? 
Because I do not find such gem with higher leading coef. I'll make another run at 40M to see if I find another one.

[QUOTE=firejuggler;349673]got a big flare [/QUOTE]
Wow! After some test sieving it is yielding better than 4:1 throughout the range. If you guys want to stop, I am happy with it. 
please wait until someone else post a poly. The skew being 4 to 5 time smaller than mine in the higher range of leading coef, it might be better than mine.

I just realized I used the wrong siever (15e). The proper one should be 14e.
I thought the sec/rel was high. Back to the drawing board. Edit: I think I am confusing myself. The 14e siever is producing half the rels at only a 20% boost in performance. I'll check back in the morning... 
nevermind , wrong seq.

Might I request one more poly? It's C169_141_71 from the xyyxf project.
[code] 1227197223602672829193383821970351855603123006836236259055513512132470494838659975966356335286773162785001346367567977767602727425980842702375345022271000585239446214933 [/code] This factorization, along with the earlier C169 poly you guys were kind enough to run, should keep me occupied into the winter. Thanks for any help. 
Aiming at setting new GNFS records for XYYXF, Sean ? :smile:
My GT540M is weak, others can help more efficiently... 
Happy to hop on that C169 once I'm finished with the C155 (although it's looking like the 1st polynomial put up by firejuggler will be the best).

All times are UTC. The time now is 16:28. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2020, Jelsoft Enterprises Ltd.