mersenneforum.org Advice on parameters for a c131 GGNFS
 Register FAQ Search Today's Posts Mark Forums Read

 2009-02-25, 10:05 #1 schickel     "Frank <^>" Dec 2004 CDP Janesville 2·1,049 Posts Advice on parameters for a c131 GGNFS I am contemplating a GGNFS job on a c131. Looking at the "def-nm-params" file I have (admittedly an old copy) this is the line for 131 digits: Code: 131,1468,1,5,7.55E+019,1.73E+018,8.41E+015,5.13E-011 Are these still good default params for a c131 poly search? Is 24 hours going to be enough or should I allow some more time? The only data point I have in this range is a c130 that I did ~4 years ago. The poly I used (using the factlat.pl script) looked like this: Code: # Murphy_E 7.02e-011 rlim: 6000000 alim: 6000000 lpbr: 27 lpba: 27 mfbr: 52 mfba: 52 rlambda: 2.9 alambda: 2.9 I have some updated lines from the GGNFS mailing list that have 11000000 as the alim/rlim values. Would that be a better value? I would be grateful for any tips from those of you who have run jobs this big.....
 2009-02-25, 14:38 #2 bsquared     "Ben" Feb 2007 334110 Posts For the C131 cofactor of 36389^41-1 I used those exact parameters and searched with -a 1500 to -A 2000. Found a 7.03e-11 murphy_E in that range which was quite a bit better than the 6.1e-11 that I expected to find. For the poly I used: Code: alim: 7500000 rlim: 7500000 lpbr: 27 lpba: 27 mfbr: 54 mfba: 54 alambda: 2.6 rlambda: 2.6 I found 13.8M relations after about 940 kiloseconds of sieving (on 1.4 GHz Opteron 240 processors) which was plenty to complete the job. hope this helps, - ben.
 2009-02-25, 14:41 #3 fivemack (loop (#_fork))     Feb 2006 Cambridge, England 6,323 Posts Time the same range of 10000 Q with alim=rlim=6M, alim=rlim=7.5M, alim=rlim=9M, alim=rlim=12M and pick whichever one's fastest, but I suspect there won't be that much of a difference.
 2009-02-25, 17:23 #4 FactorEyes     Oct 2006 vomit_frame_pointer 16416 Posts Don't ignore norm and alpha On a search for a gnfs C158 polynomial the past couple of weeks, I found a couple with Murphy scores above 1.8e-12, 4 between 1.7e-12 and 1.8e-12, and several more above 1.6e-12. I picked the top 8 Murphy scores, plus another 6 which had the largest absolute values for Alpha or had tantalizingly low norms. The top Murphy score of 1.85e-12 did belong to the best polynomial: it sieved faster than the others in all ranges. But the picture was less clear for the remaining polynomials: a couple of those with Murphy values of 1.62e-12 or so were clearly better choices than the 1.7e-12, and one with 1.64e-12 turned out to be the second best polynomial of the whole bunch. It had an alpha of -7.32 and a surprisingly low norm given the size of its leading coefficient. Scan for polynomials with decent Murphy score combined with good alpha and low norm -- they can beat polynomials with higher Murphy scores. 24 hours should be enough time for a C131 search. Last fiddled with by FactorEyes on 2009-02-25 at 17:24
 2009-02-25, 18:15 #5 10metreh     Nov 2008 91216 Posts Why has nobody suggested using msieve for the poly search?
 2009-02-25, 21:22 #6 jasonp Tribal Bullet     Oct 2004 348910 Posts Al asked me about this when he started the search; I told him that the msieve code can really only handle inputs up to 155 digits, and will use the 155-digit parameters for this 158-digit input (i.e. will probably not find any good polynomials). I don't trust the code to find good polynomials for such large inputs; really a lot of tuning and experimentation is needed to make msieve a reasonable alternative to pol5 at this input size. v1.40 will go a long way towards achieving that for the pol51opt side of things, but the initial stages will still need a lot of work. PS: msieve can pretty well for a C131, but starts to do worse as the input size goes up and the code explores less and less of the search space. In any case, all the same test sieving considerations apply; usually the best polynomial has a very good root score and very good size, but worse polynomials may only have one or the other, and it's not clear which polynomial would do better in that case Last fiddled with by jasonp on 2009-02-25 at 22:16
 2009-02-25, 22:49 #7 fivemack (loop (#_fork))     Feb 2006 Cambridge, England 6,323 Posts I have tweaked the parameter choices slightly; at the 159-digit level I've got a fair number of polynomials, including scores up to 1.47e-15, with bound1 = 2e24 bound2 = 2e22 score_lo = 1e-15 With what I think were the default parameters (!) I found a 1.67e-15 polynomial, and I should probably have been sieving with that for the past few weeks rather than continuing to hunt ...
2009-02-25, 23:36   #8
schickel

"Frank <^>"
Dec 2004
CDP Janesville

209810 Posts

Thanks for all the advice. What brought this job up was an aliquot sequence result I discovered on Wieb Bosma's webpage:
Quote:
 Note the remarkable sequence with starting value 314718. It is listed as reaching 105 digits after 8610 steps. In fact it rises up to 88 digits (around index 3250), then goes all the way down to the 5-digit minimum 16100 at index 6460 (in between dropping below 1000000 several times) and then it goes up slowly to over 100 digits. This should therefore be listed as a sequence merging with one with the smaller starting value 16100.
Furthur research by Clifford Stern revealed that 314718 actually merges with 4788, thereby moving 314718/4788 into first place as the longest sequece pair (check out the graph). Since 4788 is stable right now with $2^3$ it would be worth spending some time on factoring the current composite. (There was actually an extremely lucky break at line #8615 with an escape from the $2^3*3*5$driver, and then a continued rise until the 3 was lost on line #8717....)

A job this big would probably take ~3 weeks for me, since I've only got one machine right now that can handle something this big, although maybe I could save some hours with some more pre-testing rather than running the job as fire-and-forget... What about you, Tom, got any spare horsepower?

Last fiddled with by schickel on 2009-06-12 at 06:42

2009-02-26, 02:27   #9
FactorEyes

Oct 2006
vomit_frame_pointer

22×89 Posts

Quote:
 Originally Posted by jasonp Al asked me about this when he started the search; I told him that the msieve code can really only handle inputs up to 155 digits, and will use the 155-digit parameters for this 158-digit input (i.e. will probably not find any good polynomials).
I'm interested in doing some gnfs jobs between C130 and C162 or so -- obviously there is a limit to how much experimentation one can do at the bigger sizes, given a finite human lifespan and number of cores, as well as a finite amount of money for the electric bill, but if we can pull together a few Cunningham or BMTeR gnfs candidates in that range, we could knock over some wanted numbers while experimenting with polynomial search parameters. I'd also like to do this with the GGNFS search code. Beyond having better search algorithms, this would generate really badass polynomials for these numbers.

Quote:
 Originally Posted by schickel A job this big would probably take ~3 weeks for me, since I've only got one machine right now that can handle something this big, although maybe I could save some hours with some more pre-testing rather than running the job as fire-and-forget... What about you, Tom, got any spare horsepower?
If Tom doesn't use his core competencies on that one, I'll take it.

Last fiddled with by FactorEyes on 2009-02-26 at 02:28

2009-02-26, 03:03   #10
schickel

"Frank <^>"
Dec 2004
CDP Janesville

2×1,049 Posts

Quote:
 Originally Posted by FactorEyes If Tom doesn't use his core competencies on that one, I'll take it.
OK, I'm running some preliminary ECM work. I've logged 145 curves @ 43M and 29 curves @ 110M, along with some P+1/P-1 work at B1 ranges (default B2) from 50k to 4.2B (just finishing up 2nd of 3 P+1 runs at the top range now....) I could probably run some more ECM curves at a slightly higher level, but very slowly.....

BTW, c131=
Code:
10610277836580876222002792894053006972655975366663451742659789684697038347591723392834509640575057300905110715862343627308764000429
PS. This would be a boon; my sequences decided to stop giving up easily and I'm looking at 3 c114s in the NFS pipeline......

Last fiddled with by schickel on 2009-02-26 at 03:38 Reason: Adding PS

2009-02-26, 03:36   #11
schickel

"Frank <^>"
Dec 2004
CDP Janesville

2×1,049 Posts

Quote:
 Originally Posted by 10metreh Why has nobody suggested using msieve for the poly search?
I wasn't sure how big a number msieve's poly search could handle. Seeing the reply from Jason later on, I see that msieve is capable of handling a c131. Maybe a dual search on both sides to see which one does better.....

 Similar Threads Thread Thread Starter Forum Replies Last Post VolMike YAFU 8 2012-10-03 14:18 10metreh Aliquot Sequences 39 2009-05-03 14:02 Chris61 Factoring 13 2007-04-23 09:56 Walter Nissen GMP-ECM 16 2007-03-20 19:35 Spider Factoring 24 2006-06-05 23:42

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

Tue Nov 24 07:23:22 UTC 2020 up 75 days, 4:34, 4 users, load averages: 2.10, 1.72, 1.59