mersenneforum.org SNFS polynomial with very low yield
 User Name Remember Me? Password
 Register FAQ Search Today's Posts Mark Forums Read

 2013-04-02, 19:57 #1 ryanp     Jun 2012 Boulder, CO 4258 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, 20:16 #2 pinhodecarlos     "Carlos Pinho" Oct 2011 Milton Keynes, UK 33·181 Posts You got the right polynomial. What value did you get for skew, 0.1053241615?
2013-04-02, 20:18   #3
ryanp

Jun 2012
Boulder, CO

27710 Posts

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.

2013-04-02, 20:28   #4
ryanp

Jun 2012
Boulder, CO

277 Posts

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

2013-04-02, 20:39   #5
bsquared

"Ben"
Feb 2007

2·13·131 Posts

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)?

2013-04-02, 20:50   #6
pinhodecarlos

"Carlos Pinho"
Oct 2011
Milton Keynes, UK

33×181 Posts

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.

2013-04-02, 20:51   #7
ryanp

Jun 2012
Boulder, CO

277 Posts

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

 2013-04-02, 21:03 #8 bsquared     "Ben" Feb 2007 2×13×131 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.
 2013-04-03, 05:37 #9 ryanp     Jun 2012 Boulder, CO 277 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×1,879 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.

 Similar Threads Thread Thread Starter Forum Replies Last Post lavalamp Factoring 15 2018-02-11 14:46 mhill12 Factoring 59 2013-09-09 22:40 wblipp Factoring 6 2011-08-23 04:59 fivemack Factoring 2 2007-07-09 15:09 R.D. Silverman NFSNET Discussion 4 2007-04-11 20:39

All times are UTC. The time now is 08:25.

Wed Apr 21 08:25:48 UTC 2021 up 13 days, 3:06, 0 users, load averages: 2.42, 2.78, 2.71

Copyright ©2000 - 2021, 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.