mersenneforum.org  

Go Back   mersenneforum.org > Factoring Projects > Factoring

Reply
 
Thread Tools
Old 2009-02-25, 10:05   #1
schickel
 
schickel's Avatar
 
"Frank <^>"
Dec 2004
CDP Janesville

83216 Posts
Question 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.....
schickel is offline   Reply With Quote
Old 2009-02-25, 14:38   #2
bsquared
 
bsquared's Avatar
 
"Ben"
Feb 2007

1101000011012 Posts
Default

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.
bsquared is offline   Reply With Quote
Old 2009-02-25, 14:41   #3
fivemack
(loop (#_fork))
 
fivemack's Avatar
 
Feb 2006
Cambridge, England

6,323 Posts
Default

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.
fivemack is offline   Reply With Quote
Old 2009-02-25, 17:23   #4
FactorEyes
 
FactorEyes's Avatar
 
Oct 2006
vomit_frame_pointer

16416 Posts
Default 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
FactorEyes is offline   Reply With Quote
Old 2009-02-25, 18:15   #5
10metreh
 
10metreh's Avatar
 
Nov 2008

2·33·43 Posts
Default

Why has nobody suggested using msieve for the poly search?
10metreh is offline   Reply With Quote
Old 2009-02-25, 21:22   #6
jasonp
Tribal Bullet
 
jasonp's Avatar
 
Oct 2004

3×1,163 Posts
Default

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
jasonp is offline   Reply With Quote
Old 2009-02-25, 22:49   #7
fivemack
(loop (#_fork))
 
fivemack's Avatar
 
Feb 2006
Cambridge, England

6,323 Posts
Default

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 ...
fivemack is offline   Reply With Quote
Old 2009-02-25, 23:36   #8
schickel
 
schickel's Avatar
 
"Frank <^>"
Dec 2004
CDP Janesville

83216 Posts
Default

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*5driver, 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
schickel is offline   Reply With Quote
Old 2009-02-26, 02:27   #9
FactorEyes
 
FactorEyes's Avatar
 
Oct 2006
vomit_frame_pointer

22×89 Posts
Default

Quote:
Originally Posted by jasonp View Post
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
FactorEyes is offline   Reply With Quote
Old 2009-02-26, 03:03   #10
schickel
 
schickel's Avatar
 
"Frank <^>"
Dec 2004
CDP Janesville

2×1,049 Posts
Default

Quote:
Originally Posted by FactorEyes View Post
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
schickel is offline   Reply With Quote
Old 2009-02-26, 03:36   #11
schickel
 
schickel's Avatar
 
"Frank <^>"
Dec 2004
CDP Janesville

2·1,049 Posts
Default

Quote:
Originally Posted by 10metreh View Post
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.....
schickel is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
YAFU cli parameters VolMike YAFU 8 2012-10-03 14:18
Team sieve #3: c131 from 4788:2382 10metreh Aliquot Sequences 39 2009-05-03 14:02
C140 Parameters Chris61 Factoring 13 2007-04-23 09:56
optimal parameters for GMP-ECM , -oe+ , -I Walter Nissen GMP-ECM 16 2007-03-20 19:35
ECM parameters for RSA Spider Factoring 24 2006-06-05 23:42

All times are UTC. The time now is 22:21.

Wed Nov 25 22:21:33 UTC 2020 up 76 days, 19:32, 3 users, load averages: 1.40, 1.56, 1.52

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

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.