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 
All times are UTC. The time now is 20:07. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2020, Jelsoft Enterprises Ltd.