SNFS polynomial with very low yield

ryanp · 2013-04-02, 19:57

Hi,

So I'm working on another SNFS for the OddPerfect project: 732541^47-1 (http://www.factordb.com/index.php?id...00000517301303). I tried using the "obvious" degree-6 poly:

Code:

n: 6057169040...87
m: 732541^8
type: snfs
deg: 6
c6: 1
c0: -732541

Even using 3LP, or trying to sieve on both the algebraic and rational sides, I'm getting really poor yields. Most of the time, gnfs-lasieve4I16e (which is really lasieve5 that supports higher q values) spits out a bunch of spairs.out.* files that are empty.

Any ideas what I might be doing wrong? Is there a better polynomial I can use for this job?

pinhodecarlos · 2013-04-02, 20:16

You got the right polynomial. What value did you get for skew, 0.1053241615?

ryanp · 2013-04-02, 20:18

Quote:

Originally Posted by pinhodecarlos

You got the right polynomial. What value did you get for skew, 0.1053241615?

It got calculated quite strangely; for some reason I have 9.49.

ryanp · 2013-04-02, 20:28

Quote:

Originally Posted by ryanp

It got calculated quite strangely; for some reason I have 9.49.

Er, actually isn't 9.49 correct?

skew = (abs(c0/cN))^(1/N) = 732541^(1/6) = 9.4944976097649669448409276344264186149

bsquared · 2013-04-02, 20:39

Quote:

Originally Posted by ryanp

Er, actually isn't 9.49 correct?

skew = (abs(c0/cN))^(1/N) = 732541^(1/6) = 9.4944976097649669448409276344264186149

Yep.

For grins I tested the octic. It is way worse.

With 16e I get roughly 1 relation per special-q (i.e., 1000 rels with -c 1000), so even with 15e I don't know why you would be getting 0 output.

What are the rest of your job parameters (lpbr/a mfbr/a, r/alim, r/alambda)?

pinhodecarlos · 2013-04-02, 20:50

Quote:

Originally Posted by ryanp

Er, actually isn't 9.49 correct?

skew = (abs(c0/cN))^(1/N) = 732541^(1/6) = 9.4944976097649669448409276344264186149

You are correct. I changed the abs ratio. Sorry for that.

ryanp · 2013-04-02, 20:51

Quote:

Originally Posted by bsquared

Yep.

For grins I tested the octic. It is way worse.

With 16e I get roughly 1 relation per special-q (i.e., 1000 rels with -c 1000), so even with 15e I don't know why you would be getting 0 output.

What are the rest of your job parameters (lpbr/a mfbr/a, r/alim, r/alambda)?

Here's the full .poly.

Code:

n: 605716904027877980774625455520189647387776352555063757365644672493136637525085152114527251672682055452329862008130550673203343550128250999766605061023948523297828457779191592093682881010498969046911261346842026672855745883554109771998292748069377018429964450347583969787
m: 82919274927962023982932249248351337261442889121
type: snfs
deg: 6
c6: 1
c0: -732541
lpbr: 33
lpba: 33
mfba: 66
mfbr: 96
alambda: 2.55
rlambda: 3.7
q0: 10000000

bsquared · 2013-04-02, 21:03

Looks like you are missing the factor base bounds.

i.e., something like:

Code:

rlim: 300000000
alim: 300000000

The actual bounds could probably be optimized over the above, but these should be in the right ballpark.

ryanp · 2013-04-03, 05:37

Thanks for the suggestion about rlim and alim. Unfortunately, that produces no change in the sieving.

The strange thing is that gnfs-lasieve4I16e is producing spairs.out.* files; they all just seem to be empty. (Or at least, the overwhelming majority of them. Every now and then, I'll get a "q" range that has at least some small yield).

I don't see anything else unusual about this poly... are there other parameters that need tweaking?

Batalov · 2013-04-03, 06:33

Try the lasieve4 variant. These two branches are fairly divergent, and certain problems were fixed in the "4" branch (which I have used extensively and patched), but not in the "5" branch (which was ported from CWI to GG i/o and patched by Greg).

In other words, while using the "5" branch - your only colleague is Greg. Everyone else is using the "4" branch.

If you will get different results with 4I16e (I did run your poly and its three flipped variants {-a/-r}*{3LP on a/on r side} and concur with Ben's message above: there's a normal if a bit subdued flow of relations), let's have a good long look together at the source.

2013-04-02, 19:57	#1
ryanp Jun 2012 Boulder, CO 263₁₀ Posts	SNFS polynomial with very low yield Hi, So I'm working on another SNFS for the OddPerfect project: 732541^47-1 (http://www.factordb.com/index.php?id...00000517301303). I tried using the "obvious" degree-6 poly: Code: n: 6057169040...87 m: 732541^8 type: snfs deg: 6 c6: 1 c0: -732541 Even using 3LP, or trying to sieve on both the algebraic and rational sides, I'm getting really poor yields. Most of the time, gnfs-lasieve4I16e (which is really lasieve5 that supports higher q values) spits out a bunch of spairs.out.* files that are empty. Any ideas what I might be doing wrong? Is there a better polynomial I can use for this job?

2013-04-02, 21:03	#8
bsquared "Ben" Feb 2007 3,371 Posts	Looks like you are missing the factor base bounds. i.e., something like: Code: rlim: 300000000 alim: 300000000 The actual bounds could probably be optimized over the above, but these should be in the right ballpark.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Choice of SNFS polynomial degree	lavalamp	Factoring	15	2018-02-11 14:46
SNFS Polynomial selection help?	mhill12	Factoring	59	2013-09-09 22:40
SNFS Polynomial for 919^87-1	wblipp	Factoring	6	2011-08-23 04:59
Concocting an SNFS polynomial for 2^2376-1	fivemack	Factoring	2	2007-07-09 15:09
SNFS Polynomial	R.D. Silverman	NFSNET Discussion	4	2007-04-11 20:39

2013-04-02, 20:16	#2
pinhodecarlos "Carlos Pinho" Oct 2011 Milton Keynes, UK 1301₁₆ Posts	You got the right polynomial. What value did you get for skew, 0.1053241615?

2013-04-03, 05:37	#9
ryanp Jun 2012 Boulder, CO 263₁₀ Posts	Thanks for the suggestion about rlim and alim. Unfortunately, that produces no change in the sieving. The strange thing is that gnfs-lasieve4I16e is producing spairs.out.* files; they all just seem to be empty. (Or at least, the overwhelming majority of them. Every now and then, I'll get a "q" range that has at least some small yield). I don't see anything else unusual about this poly... are there other parameters that need tweaking?

2013-04-03, 06:33	#10
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 5²·373 Posts	Try the lasieve4 variant. These two branches are fairly divergent, and certain problems were fixed in the "4" branch (which I have used extensively and patched), but not in the "5" branch (which was ported from CWI to GG i/o and patched by Greg). In other words, while using the "5" branch - your only colleague is Greg. Everyone else is using the "4" branch. If you will get different results with 4I16e (I did run your poly and its three flipped variants {-a/-r}*{3LP on a/on r side} and concur with Ben's message above: there's a normal if a bit subdued flow of relations), let's have a good long look together at the source.