mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Factoring (https://www.mersenneforum.org/forumdisplay.php?f=19)
-   -   SNFS polynomial with very low yield (https://www.mersenneforum.org/showthread.php?t=18052)

 ryanp 2013-04-02 19:57

SNFS polynomial with very low yield

Hi,

So I'm working on another SNFS for the OddPerfect project: 732541^47-1 ([url]http://www.factordb.com/index.php?id=1100000000517301303[/url]). I tried using the "obvious" degree-6 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, 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=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.

 ryanp 2013-04-02 20:28

[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

 bsquared 2013-04-02 20:39

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

 ryanp 2013-04-02 20:51

[QUOTE=bsquared;335895]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)?[/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]

 bsquared 2013-04-02 21:03

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.

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

 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.

 All times are UTC. The time now is 21:13.