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.276810e-20 alpha -9.238464 e 9.932e-16 rroots 5 skew: 380780879.24
# norm 1.161363e-20 alpha -9.018629 e 9.234e-16 rroots 5 skew: 609572156.15
# norm 1.358701e-20 alpha -6.910857 e 1.038e-15 rroots 5 skew: 104279094.33
# norm 1.270759e-20 alpha -7.678108 e 9.961e-16 rroots 3 skew: 291528643.68

Degree 6
# norm 2.827871e-015 alpha -10.512910 e 9.028e-016 rroots 2 skew: 1564743.15
# norm 3.242080e-015 alpha -9.429823 e 1.024e-015 rroots 4 skew: 1013932.94
# norm 3.252680e-015 alpha -7.597478 e 1.032e-015 rroots 6 skew: 830332.96
# norm 3.384932e-015 alpha -7.504910 e 1.054e-015 rroots 6 skew: 673235.34
# norm 3.617168e-015 alpha -7.884669 e 1.120e-015 rroots 6 skew: 741885.74
# norm 3.407911e-015 alpha -8.473234 e 1.056e-015 rroots 6 skew: 788144.46
# norm 3.211134e-015 alpha -9.178180 e 1.016e-015 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 RSA-c212:
[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 E-value 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 E-value 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 E-values. 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 E-values with degree 6.

The change to the E-value 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 C155-180s 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 core-week 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 157-digit GNFS candidates:
[CODE](181^103-1)/((181-1)*7417*3386023*1622748672647*767015484026387551*1656939272001358583196903067208809)
(877^79-1)/((877-1)*4583*208520387347*96078130292657*103086319456710261705085017633872730943681601)
(5591^61-1)/((5591-1)*16556099215542617537*743213379283195327995487*11686924821525596917649777)
(421^101-1)/((421-1)*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^131-1: 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.949172e-015 alpha -8.210982 e 2.273e-012 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.542e-015, alpha -7.552, combined = 2.295e-012 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.533e-015, alpha -4.681, combined = 2.342e-012 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 15-digit factors
Mon Jul 08 11:37:16 2013 commencing number field sieve (155-digit 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 E-value: 2.15e-012
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.737e-015, alpha -7.395, combined = 2.379e-012 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 15-digit factors
Mon Jul 08 11:40:50 2013 commencing number field sieve (155-digit 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 E-value: 2.15e-012
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.631e-015, alpha -6.985, combined = 2.377e-012 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 sur-evaluated 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.916149e-015 alpha -7.119644 e 1.883e-012 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 CPU-time.

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 GPU-power 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 GPU-target range every time, but doing your poly selects beats LLR-cuda as a good use of my GPU.

Repeated searches in the C155+ region give me some incentive to learn how to test-sieve, which leads to fiddling with the knobs as Jason puts it. All useful knowledge, and possibly heading for a beginner-guide mid-level GNFS entry.

GPU ideas: Go cheap, just get anything that supports the right flavor of CUDA. Even a low-end current card will be 50-100x 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 GPU-target range every time, but doing your poly selects beats LLR-cuda as a good use of my GPU.

Repeated searches in the C155+ region give me some incentive to learn how to test-sieve, which leads to fiddling with the knobs as Jason puts it. All useful knowledge, and possibly heading for a beginner-guide mid-level GNFS entry.

GPU ideas: Go cheap, just get anything that supports the right flavor of CUDA. Even a low-end current card will be 50-100x faster for stage 1, while using fewer watts than a $100+ card.[/QUOTE]
Well, I actually have a CUDA-capable GPU. But it is weak, and has few cores. And it is hooked up to my main screen.
There are currently five p^q-1-GNFS-candidates in the range 154-156. I could pretest some above 160 as well. I also have my eyes on a HP-number 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 600-series, and so should be a good choice I suppose.
The 6- & 700-series 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 sur-evaluate the poly score a bit.

1.51, svn 845 (I think). April 2013 download, premade binary. It should be the newer/lower E-values.

My GPU also drives my main screen, and the only time response has slowed was on the C210 sextic search. I've run cuda-LLR 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 mobile-GPU 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 half-dozen 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.287e-015, alpha -6.085, combined = 1.833e-012 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.62e-012 to > 3.02e-012

R0: -1982277912715175423679197808784
R1: 69837075648803257
A0: -44322257284138334787861242542456972633815
A1: 9286106559194619360096878548752378
A2: 108520072080442627462348267
A3: -10202649139317912268
A4: -61572653402
A5: 1740
skew 45960569.14, size 4.023e-015, alpha -7.466, combined = 2.541e-012 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.601e-015, alpha -7.664, combined = 1.978e-012 rroots = 3
[/code]

Here is the poly for 39^158+1:
[CODE] # norm 5.644615e-015 alpha -7.931357 e 2.775e-012 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 (150-170 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 176-digit 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 155-digit 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 sieve-time 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 far--it's a fair bit under the expected range:

[CODE]
expecting poly E from 1.46e-013 to > 1.68e-013
R0: -2988691192272804298611698595599499
R1: 237161778113747539
A0: 32731363407803097195252649322319485122428800
A1: 3923946321852883713926555500462761080
A2: -1172068129952158854846849214634
A3: -65955053275793992651415
A4: 8394258833127276
A5: 100009980
skew 13540340.13, size 2.166e-017, alpha -8.427, combined = 1.085e-013 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.263e-017, alpha -6.468, combined = 1.142e-013 rroots = 3[/CODE]

Skews for coeff = 23M are 7-12M for alphas in the 6's, 11 to 16M for alpha over 7. Best score after a few hours is 1.24e-13 w/skew 8.7M.

Update: Score 1.32e-13, 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.744e-017, alpha -6.656, combined = 1.281e-013 rroots = 5
[/code]

To clarify my last post, I'm now sieving 84^131-1 (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.5e-12 instead of default 3.63e-12).

Are there numbers where the polys found are just terrible compared to expectations? I just loosened the min value to 3.0e-12, 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 3-6M range, which seems pretty standard for a C152.

Edit: Should I experiment with stage-2 norm for the npr step?

I think there are still some infelicities in the table of norms and min-E; 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 1000-A5 range. But running 3936090042216234613709067994268312375269653484027874112960552153626006376667321970650341587753839767751476856325227586616119340003347991887464416435517 (151 digits) last week I got no more than ten polynomials in some such ranges.

For 4202701474560599145864668379214403877602720577806362075074321031589277391358279336093140444841799054199486202393045071085680275027063857193327313335405064090859 I got 3-5k polynomials for each 1000-A5 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 400-420M range than what I already posted for the C176

for (421^101-1)/((421-1)*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.041e-015, alpha -8.806, combined = 2.126e-012 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.267e-015, alpha -5.886, combined = 1.806e-012 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.728e-017, alpha -8.174, combined = 1.281e-013 rroots = 3[/CODE]

Each 5-digit increase in size takes roughly double the effort to sieve- and should have a corresponding increase in poly-select 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 155-157s 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.45e-13 at minimum.

(421^101-1)/((421-1)*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.688e-015, alpha -7.134, combined = 2.021e-012 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 (150-170 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.875e-017, alpha -8.679, combined = 1.327e-013 rroots = 3
[/code]
now will give a nudge to
[code]
86026587992252713187749194939696412639941777372908947403799022828963200928303537489025731813345034713461276262988371957157619420275286481805832459392273827
[/code]

(the 155-digit 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.55e-012 to > 2.93e-012
R0: -968570173465693155394698061307
R1: 475524413938021
A0: 428389013154971721280710914712321354000
A1: 292799622011886831826018199855838
A2: -9878586190707635075783980
A3: -13948567785977503723
A4: 427349694910
A5: 100920
skew 6966773.42, size 4.361e-015, alpha -7.161, combined = 2.665e-012 rroots = 5
[/code]

I'll give the C169 an overnight run too, and then run the c176 while away on another trip wed-sun.
No improvement in day 2 of C176 from the 1.32e-13 I had in day 1.

To throw in with Curtis on the C176, I still haven't managed anything better than 1.281e-13. Still working on it, though.

Polynomial Request Thread
 

Far be it for me in all my newbie-ness 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 stuff--if 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.087e-015, alpha -6.778, combined = 2.603e-012 rroots = 3
[/code]
Now, onto C169_123_109

Day 1 on the C169 produced 3.315e-13. I'll put a second day on it before resuming the C176.

Day 1 for the C169 produced a 3.694e-13
[code]
R0: -384580347035682112978309208888480
R1: 7069004002408717
A0: 3465513533571190599220783764906879085904469
A1: 1069822016219563236870593762230230147
A2: 66001602968642015370778936319
A3: -270830722426445846387
A4: -30351561461328
A5: 261900
skew 42174313.97, size 1.629e-016, alpha -7.922, combined = 3.694e-013 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.841e-016, alpha -6.366, combined = 4.109e-013 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.489e-016, alpha -6.645, combined = 3.600e-013 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.28e-13 (best is 1.32e-13 with expected of at least 1.46e-13).

Just wanted to note that with the latest SVN (922), the e-score calculation has been revised, and the C176 now has an expected score of

[CODE]expecting poly E from 1.32e-013 to > 1.51e-013[/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 (r838-r920), 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 well-trodden 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 GPU-assisted 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.498911e-017 alpha -7.554399 e 1.321e-013 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.445278e-017 alpha -6.820795 e 1.321e-013 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 trial-sieving 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 trial-sieving purposes also.

Stupid question about trial-sieving:

Is that essentially seeing how many relations/sec one gets with a given polynomial?

[QUOTE=wombatman;347260]Stupid question about trial-sieving:

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 full-scale 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 trial-sieving mattering less for us- if, say, 3 human-hours 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 GNFS-150s, 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 GNFS-150, 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 CPU-centuries[/url]. :max:

All IMHO of course.

[QUOTE=VBCurtis;347285]I, too, have an i7 laptop as my factoring tool. You're mostly right about trial-sieving mattering less for us- if, say, 3 human-hours 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 GNFS-150s, 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 GNFS-150, 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 CPU-centuries[/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 start-to-finish, 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 CUDA-based 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.501e-017, alpha -7.824, combined = 2.190e-013 rroots = 5[/code]

Here are my 3rd and 4th best polys for Tom's C176:
[CODE]n: 23847813234751095518553790092375554156554053397317779773831395300907022889988067196688707035368393323174109573706580716877436977083912429179428455659750299481884888866554791173
# norm 3.325425e-017 alpha -7.877752 e 1.295e-013 rroots 3
skew: 5951640.57
c0: -258966513599481929079497470679516666534935
c1: 285698172063866150512027099539634511
c2: 36140358534479527549329501741
c3: -23721865971444823325851
c4: 2071207813249694
c5: 189059640
Y0: -2631297462869838988968661000353606
Y1: 203813686529856847

# norm 3.367613e-017 alpha -7.168929 e 1.301e-013 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.32e-13 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 4-5 GPU-days 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.869e-015, alpha -6.105, combined = 3.230e-012 rroots = 5
[/code]

What's the E-score range for it? (I'm at work, my msieve is running at home)

Expecting poly E from 2.88e-012 to > 3.31e-012

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).