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[/code]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[/code]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.....

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
[/CODE]

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.

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.

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.

Why has nobody suggested using msieve for the poly search?

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

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

Thanks for all the advice. What brought this job up was an aliquot sequence result I discovered on [url="http://www.math.ru.nl/~bosma/Projects/tabB.html"]Wieb Bosma's webpage:[/url][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. [/quote]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 [url="http://www.lafn.org/~ax810/graphs.htm#314718"]graph[/url]). Since 4788 is stable right now with [tex]2^3[/tex] 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 [tex]2^3*3*5[/tex]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?

[QUOTE=jasonp;164000]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).[/QUOTE]

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=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?[/QUOTE]
If Tom doesn't use his core competencies on that one, I'll take it.

[QUOTE=FactorEyes;164030]If Tom doesn't use his core competencies on that one, I'll take it.[/QUOTE]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
[/code]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......

[QUOTE=10metreh;163980]Why has nobody suggested using msieve for the poly search?[/QUOTE]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.....