SNFS polynomial with very low yield
Hi,
So I'm working on another SNFS for the OddPerfect project: 732541^471 ([url]http://www.factordb.com/index.php?id=1100000000517301303[/url]). I tried using the "obvious" degree6 poly: [code]n: 6057169040...87 m: 732541^8 type: snfs deg: 6 c6: 1 c0: 732541[/code] Even using 3LP, or trying to sieve on both the algebraic and rational sides, I'm getting really poor yields. Most of the time, gnfslasieve4I16e (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? 
You got the right polynomial. What value did you get for skew, 0.1053241615?

[QUOTE=pinhodecarlos;335889]You got the right polynomial. What value did you get for skew, 0.1053241615?[/QUOTE]
It got calculated quite strangely; for some reason I have 9.49. 
[QUOTE=ryanp;335891]It got calculated quite strangely; for some reason I have 9.49.[/QUOTE]
Er, actually isn't 9.49 correct? skew = (abs(c0/cN))^(1/N) = 732541^(1/6) = 9.4944976097649669448409276344264186149 
[QUOTE=ryanp;335894]Er, actually isn't 9.49 correct?
skew = (abs(c0/cN))^(1/N) = 732541^(1/6) = 9.4944976097649669448409276344264186149[/QUOTE] Yep. For grins I tested the octic. It is way worse. With 16e I get roughly 1 relation per specialq (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)? 
[QUOTE=ryanp;335894]Er, actually isn't 9.49 correct?
skew = (abs(c0/cN))^(1/N) = 732541^(1/6) = 9.4944976097649669448409276344264186149[/QUOTE] You are correct. I changed the abs ratio. Sorry for that. 
[QUOTE=bsquared;335895]Yep.
For grins I tested the octic. It is way worse. With 16e I get roughly 1 relation per specialq (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)?[/QUOTE] 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[/code] 
Looks like you are missing the factor base bounds.
i.e., something like: [CODE] rlim: 300000000 alim: 300000000 [/CODE] The actual bounds could probably be optimized over the above, but these should be in the right ballpark. 
Thanks for the suggestion about rlim and alim. Unfortunately, that produces no change in the sieving.
The strange thing is that gnfslasieve4I16e 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? 
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. 
All times are UTC. The time now is 21:13. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2021, Jelsoft Enterprises Ltd.