mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Msieve (https://www.mersenneforum.org/forumdisplay.php?f=83)
-   -   Polynomial Request Thread (https://www.mersenneforum.org/showthread.php?t=18368)

chris2be8 2013-07-14 16:34

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.

firejuggler 2013-07-14 16:46

Will work on the fourth number of post 85 once i'm done proccessing the hits on the C176

VBCurtis 2013-07-14 16:55

Chris-
See post #123 for the poly for the middle number.
-Curtis

VBCurtis 2013-07-14 21:39

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?

fivemack 2013-07-14 23:09

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

jasonp 2013-07-14 23:09

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.

firejuggler 2013-07-15 00:22

nothing better in the 400-420M range than what I already posted for the C176

firejuggler 2013-07-15 02:21

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

wombatman 2013-07-15 03:05

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]

VBCurtis 2013-07-15 04:26

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.

firejuggler 2013-07-15 09:45

(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


All times are UTC. The time now is 20:07.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.