How to identify SNFS candidates and factor them?

[axn]

Originally Posted by bur

Interesting, is there a way to know if GNFS is faster or does it just turn out by experiment?

There is some rule of thumb regarding SNFS-GNFS equivalency. I think ratio of SNFS size:GNFS size of about 1.3 (?) is roughly equivalent. Here 175/119 = 1.47 is clearly favoring GNFS. SNFS 175 should be equivalent to GNFS 130 (+/-).

Of course, not all SNFS 175 are equal. And the 1.3 might not be the proper value. So, it is a good starting point to check if one or the other is clearly superior, but not definitive.

[firejuggler]

I think I saw somewhere that
snfs difficulty =(digit lenght-30)*1.5
Wich is close to what axn said.

[charybdis]

You can use Murphy-E scores as given by cownoise/msieve to compare polynomials as long as they have the same degree. Helpfully this is a degree 5 SNFS polynomial, so we can compare it to GNFS polynomials in the right range. The score of ~9e-11 is comparable to the score of a typical GNFS-130 polynomial. 175/130 = 1.35 so that's a good ratio to use for these numbers.

Originally Posted by axn

Of course, not all SNFS 175 are equal. And the 1.3 might not be the proper value. So, it is a good starting point to check if one or the other is clearly superior, but not definitive.

Indeed. The big c5 coefficient makes this number more difficult than a "typical" SNFS-175. An SNFS-175 polynomial with small algebraic coefficients scores more like GNFS-123, suggesting a ratio of ~1.42 rather than 1.3 or 1.35. Though I'd guess a lot of SNFS-175s being done these days don't have small algebraic coefficients.

I believe the ratio gets larger as numbers get bigger. 1.42 would suggest SNFS-250 is as hard as GNFS-176, which it isn't.

Originally Posted by firejuggler

I think I saw somewhere that
snfs difficulty =(digit lenght-30)*1.5
Wich is close to what axn said.

This must have a typo? (130-30)*1.5 = 150...

[richs]

Batalov told me this:

The short rule of thumb is gnfs_size < 0.56 * S +30 where S is SNFS difficulty.

[bur]

So the difficulty to factor a co-factor of a "special number" is entirely determined by the size of the special number? Or does the co-factor size also play a role? I guess the latter?



And at roughly which digit length should I switch to c130 parameters? VBcurtis mentioned approximately every 30 bits I should switch +5 digits for the params, but at what starting points?

[axn]

Originally Posted by bur

So the difficulty to factor a co-factor of a "special number" is entirely determined by the size of the special number? Or does the co-factor size also play a role? I guess the latter?

The former. Using the cofactor helps in the final sqrt phase when it is doing the gcd to extract factors. That'll avoid reporting small (previously known, redundant) factors.

[VBCurtis]

Originally Posted by bur

And at roughly which digit length should I switch to c130 parameters? VBcurtis mentioned approximately every 30 bits I should switch +5 digits for the params, but at what starting points?

As you get into jobs that take days rather than hours, you'll want to test-sieve parameters yourself. There aren't solid rules-of-thumb for SNFS jobs like there are for GNFS, because optimal parameter choice depends in part on the size of coefficients in the poly.

That said, the formula given the post before yours allows you to plug in 130 for GNFS and solve for S; I get 180 or so. By the time you're at 200 digits, you ought to test params yourself or study the 14e queue submissions in NFS@home subforum to see what params were chosen for SNFS jobs of similar size. That research should keep you out of trouble of the "oops this job took twice as long as it should have" sense. When in doubt, use the bigger large-prime option.

[bur]

Ok, so I roughly chose the params for a GNFS composite of the same difficulty? 180 would agree with my current plan, I used params.c120 for 520, switched to 125 at 550 and next at 580 would be up.


So far the longest SNFS took about 5 h for sieving, so I'm still far from days.