Running GGNFS

[Batalov]

Well, then it's best to Windows-awarely "chomp" in line 1700.

  s/\s+$//;

[mataje]

Jeff, I´m using your GGNFS files (v339) and factmsieve.pl and I have get this error with polynomial selection:
-> Searching leading coefficients from 86001 to 87000.
=> "C:/Users/Ignacio/Documents/G339/pol51m0b.exe" -b vv.polsel.Ignacio1.3196 -v
-v -p 4 -n 8.13E+014 -a 86 -A 87 > vv.polsel.Ignacio1.3196.log
lambda-comp
Abnormal return value 256. Terminating...

Is that a bug?

[Batalov]

Please see post 112. Yes, it is an old known bug; no-one knows that part well enough to fix (the parameter file may alternatively need fixing), but the workaround in the perl script may help.

Here's the highlighted change in the script; if you are using factLat.pl, you may use the same patch. Good luck factoring!

[Jeff Gilchrist]

Originally Posted by Batalov

Well, then it's best to Windows-awarely "chomp" in line 1700.

  s/\s+$//;

Ah, you just fixed the code in svn340 I see. Thanks. Time to update my package.

Jeff.

[mdettweiler]

Hi,

Just now I tried running a GNFS factorization based on Jeff's guide for polynomial selection using msieve. The number is a C107 from some Aliquot sequence work I'm doing and took about 40 minutes for msieve to find an optimal polynomial when run with the -np switch. Here's the polynomial I got:

N 28920454274023379407585900683723407567317016533970617364673384087817849013202048602792622724241676931623691
R0 -2157350365847100500
R1  1
A0 -36770012058151309
A1  35620331673416050
A2 -9289211598809493
A3  19515005648358552
A4  9218535440569200
A5  618873229578240

So far, so good. I then ran the msieve.fb file through the convertpoly.sh script linked from Jeff's tutorial and got this:

n: 28920454274023379407585900683723407567317016533970617364673384087817849013202048602792622724241676931623691
Y0: -2157350365847100500
Y1:  1
c0: -36770012058151309
c1:  35620331673416050
c2: -9289211598809493
c3:  19515005648358552
c4:  9218535440569200
c5:  618873229578240

type: gnfs

I then tried running this polynomial with gnfs-lasieve4I12.exe and got the following error:

'Please set all bounds to reasonable values!'

Does anyone know what might be causing this? I noticed that in the tutorial's example polynomial, there was a line labeled "skew:" that is not present in either the msieve or gnfs format polynomial that I just generated. Did something go wrong along the way when I generated my polynomial?

Thanks,
Max

[axn]

Did you try to directly invoke the siever or use factMsieve.pl? If it is a direct run, you need to set all the alim, rlim, lpba, ... stuff. Using factMsieve.pl will fill that for you.

Yes, skew also need to be set. Don't know what a good value is, but for such a small job, skew of 1 should work (I guess!)

[mdettweiler]

Originally Posted by axn

Did you try to directly invoke the siever or use factMsieve.pl? If it is a direct run, you need to set all the alim, rlim, lpba, ... stuff. Using factMsieve.pl will fill that for you.

Yes, skew also need to be set. Don't know what a good value is, but for such a small job, skew of 1 should work (I guess!)

I was trying to directly invoke the siever. Okay, that makes sense now--I didn't realize that factMsieve does all that stuff for you.

Though, indeed, I could have sworn I read somewhere that msieve is supposed to output the skew value, at least, in the polynomials it generates. I think the exact line I remember was something along the lines of (heavily paraphrased) "msieve searches a much bigger range of skews than the pol51 tools", from which I inferred that the skew value was an inherent part of the polynomial-searching process. In fact, Jeff's guide to polynomial generation with msieve seemed to show that the skew was present in the polynomial file from the moment msieve had finished generating it with the -np switch. That's why I was wondering whether something was wrong when I didn't see that value present in my output.

[schickel]

Originally Posted by mdettweiler

n: 28920454274023379407585900683723407567317016533970617364673384087817849013202048602792622724241676931623691
Y0: -2157350365847100500
Y1:  1
c0: -36770012058151309
c1:  35620331673416050
c2: -9289211598809493
c3:  19515005648358552
c4:  9218535440569200
c5:  618873229578240

type: gnfs

axn beat me to the punch....if the above is the complete poly file, there are a few values missing. From a c107 that I ran, here's the missing items:

rlim: 2500000
alim: 2500000
lpbr: 26
lpba: 26
mfbr: 49
mfba: 49
rlambda: 2.6
alambda: 2.6
qintsize: 100000

The skew for this poly was 16000+, it really depends on the poly. I'm not sure how much it's going to affect it. The post-processing on this was done with GGNFS, so you can probably get away with fewer unique relations. Here's the stats from the run:

largePrimes:4588182 encountered
Relations: rels:4835816

So you need somewhere under 5M realtions.

[mdettweiler]

Originally Posted by schickel

axn beat me to the punch....if the above is the complete poly file, there are a few values missing. From a c107 that I ran, here's the missing items:

rlim: 2500000
alim: 2500000
lpbr: 26
lpba: 26
mfbr: 49
mfba: 49
rlambda: 2.6
alambda: 2.6
qintsize: 100000

The skew for this poly was 16000+, it really depends on the poly. I'm not sure how much it's going to affect it. The post-processing on this was done with GGNFS, so you can probably get away with fewer unique relations. Here's the stats from the run:

largePrimes:4588182 encountered
Relations: rels:4835816

So you need somewhere under 5M realtions.

Okay, thanks. I tried adding those values to my poly file, and setting the skew to 1.0 as axn suggested, and now gnfs-lasieve4I12e seems to accept the file correctly. This is the yield I'm getting with algebraic side sieving starting at the alim:
total yield: 6805, q=2502833 (0.01119 sec/rel)
I presume that's a reasonbly good enough amount to say that I've at least got a half-decent polynomial set up now? (i.e. did setting the skew to 1.0 somehow turn a great polynomial into a somewhat lame one?)

[schickel]

Originally Posted by mdettweiler

total yield: 6805, q=2502833 (0.01119 sec/rel)

So it looks like a yield of ~2.5 relations per Q, which is actually better than the yield on my job. The scripts start sieving at 1/2 the alim to take advantage of the increased yield at lower Qs, but that should be OK. I had to sieve 2.75M Qs to get enough relations, so you can take your "sec/rel" value and multiply by approx 2.5 million and see how long that is....I make it in the neighborhood of 9 hours. Not bad for a c107!

I presume that's a reasonbly good enough amount to say that I've at least got a half-decent polynomial set up now? (i.e. did setting the skew to 1.0 somehow turn a great polynomial into a somewhat lame one?)

Without spending some time playing with skew and yields, probably not worth losing sleep over. You've got a good system there. My c107 ran about 17 hours on a 3GHz Athlon...

[Andi47]

Originally Posted by mdettweiler

Hi,

Just now I tried running a GNFS factorization based on Jeff's guide for polynomial selection using msieve. The number is a C107 from some Aliquot sequence work I'm doing and took about 40 minutes for msieve to find an optimal polynomial when run with the -np switch. Here's the polynomial I got:

N 28920454274023379407585900683723407567317016533970617364673384087817849013202048602792622724241676931623691
R0 -2157350365847100500
R1  1
A0 -36770012058151309
A1  35620331673416050
A2 -9289211598809493
A3  19515005648358552
A4  9218535440569200
A5  618873229578240

So far, so good. I then ran the msieve.fb file through the convertpoly.sh script linked from Jeff's tutorial and got this:

n: 28920454274023379407585900683723407567317016533970617364673384087817849013202048602792622724241676931623691
Y0: -2157350365847100500
Y1:  1
c0: -36770012058151309
c1:  35620331673416050
c2: -9289211598809493
c3:  19515005648358552
c4:  9218535440569200
c5:  618873229578240

type: gnfs

This polynomials look like it has been found by msieve 1.38 or older - the polys found by these versions are quite ugly.

Download msieve 1.39 to do polynomial search, this version finds MUCH better polynomials.