Pascal's OPN roadblock files

[charybdis]

Originally Posted by henryzz

Unless I have made a mistake:

f(x)=x^8+x^7-7x^6-6x^5+15x^4+10x^3-10x^2-4x+1
g(x)=6115909044841454629x-6115909044841454629^2-1

Correct :)

What size have the previous reciprocal octics been?

As far as I can tell, they range from difficulty 183 to 225, so we don't have much idea of what to expect from larger octics.
I guess there just haven't been many targets in the "16e" range, because for Cunningham numbers of the form b^(17k)-1 it's still faster to use the sextic and ignore the algebraic factor; it's the inconveniently large b that's stopping us from doing that here (it would be diff-320 without the algebraic factor, but we have to multiply by b in order to use a sextic).

[henryzz]

Originally Posted by charybdis

Correct :)




As far as I can tell, they range from difficulty 183 to 225, so we don't have much idea of what to expect from larger octics.
I guess there just haven't been many targets in the "16e" range, because for Cunningham numbers of the form b^(17k)-1 it's still faster to use the sextic and ignore the algebraic factor; it's the inconveniently large b that's stopping us from doing that here (it would be diff-320 without the algebraic factor, but we have to multiply by b in order to use a sextic).

Octics shouldn't be anywhere near as bad at 300 digits as 225. If your estimate is that 225 acts as 255 then I would imagine that 300 could act as low as 310. Test sieving is probably the way to solve this.

[charybdis]

Originally Posted by henryzz

Octics shouldn't be anywhere near as bad at 300 digits as 225. If your estimate is that 225 acts as 255 then I would imagine that 300 could act as low as 310. Test sieving is probably the way to solve this.

I expect the gap will be smaller, yes - though 225 may be acting as 265, after all I've only got msieve logs to go on, not sieving data.

But the octic still has rather unbalanced norms: guesstimating that a typical lattice point is (10^9, 10^9), we get rational norm ~10^47 and algebraic norm ~10^72. A difficulty-310 sextic with small coefficients would have rational norm ~10^61 and algebraic norm ~10^54, so the product of the norms is smaller for the sextic and they're more balanced. Increasing the difficulty of the sextic by 6 digits adds a power of 10 to the rational norm, so this would suggest we'd need to go up to around sextic-335 to get the products equal.

This is all guesswork, but I'd be rather surprised if octic-301 was faster than sextic-320, for example.

[VBCurtis]

And, since the poly is posted here, I can do that test-sieve this weekend, too!

Whether it's similar to sextic-310 or -340, we still need a ton of ECM.

I agree with the observation that octics will get less-gnarly as difficulty increases- by SNFS-450 or so, an octic should be faster than a sextic of the same snfs-difficulty! My uneducated guess is that it'll be tractable with 16e, something akin to a sextic at 315-320 digits.

Edit2: Charybdis, the unbalanced norms suggest looser alg-side bounds, right? I should test-sieve like 33/34 and 33/35, I think.

[charybdis]

Originally Posted by VBCurtis

Edit2: Charybdis, the unbalanced norms suggest looser alg-side bounds, right? I should test-sieve like 33/34 and 33/35, I think.

Yes - and sieving and 3LP should be on the algebraic side too of course. Though NFS@home never goes above 33-bit large primes I believe?

[VBCurtis]

That's correct, but the 16e queue can handle 34LP as far as I know. Frmky believes that the disk space and msieve headaches (from back when big data sets could foul msieve filtering, say > 800M unique rels) did not justify the efficiency gains from using 34LP.

I think we could attempt a 32/34 quartic or octic on 16e, so I guess I'll test that too if yield on 33/35 or 33/34 suggests it's reasonable.

I appreciate the reminder to sieve -a side! I would have tested both (and I might anyway, a 1kQ test isn't hard on -r side to see how bad it is).

[RichD]

Originally Posted by VBCurtis

Thanks! I'll start some ECM on the C301 at B1 = 15e7 tonight.

There has already been at least 30K @ 29e8 (if not more) and 10K @ 76e8 on this number.

[charybdis]

Originally Posted by VBCurtis

That's correct, but the 16e queue can handle 34LP as far as I know. Frmky believes that the disk space and msieve headaches (from back when big data sets could foul msieve filtering, say > 800M unique rels) did not justify the efficiency gains from using 34LP.

I think we could attempt a 32/34 quartic or octic on 16e, so I guess I'll test that too if yield on 33/35 or 33/34 suggests it's reasonable.

I appreciate the reminder to sieve -a side! I would have tested both (and I might anyway, a 1kQ test isn't hard on -r side to see how bad it is).

Aha, this reminds me: due to the peculiar nature of this polynomial, even yield per 10kQ on the algebraic side will be highly variable. For 7/8 of all primes p, the algebraic poly has no roots mod p, and so this p cannot be a special-q. For the remaining 1/8 of the primes (those with p=+-1 mod 17), the algebraic poly splits completely mod p, so we get 8 special-q from that one prime! In the long run, we will get one special-q per prime on average, as usual. But there will be a LOT of variation over small ranges, so pay attention to rels/sec and yield *per special-q*, rather than yield in a range of a given size.

[ryanp]

Originally Posted by VBCurtis

That's correct, but the 16e queue can handle 34LP as far as I know. Frmky believes that the disk space and msieve headaches (from back when big data sets could foul msieve filtering, say > 800M unique rels) did not justify the efficiency gains from using 34LP.

I think we could attempt a 32/34 quartic or octic on 16e, so I guess I'll test that too if yield on 33/35 or 33/34 suggests it's reasonable.

I appreciate the reminder to sieve -a side! I would have tested both (and I might anyway, a 1kQ test isn't hard on -r side to see how bad it is).

I'd be interested in taking a crack at this one, if someone can provide the poly/params.

[VBCurtis]

Originally Posted by ryanp

I'd be interested in taking a crack at this one, if someone can provide the poly/params.

Give me the weekend to do some testing- my university course grades are due Monday, so maybe I need till monday night, but I'll provide at-least-decent params for the poly posted a few posts ago.

Will you be CADOing or ggnfs-16e? If cado, I will likely test larger LPs than with ggnfs.

[ryanp]

Originally Posted by VBCurtis

Give me the weekend to do some testing- my university course grades are due Monday, so maybe I need till monday night, but I'll provide at-least-decent params for the poly posted a few posts ago.

Thanks!

Will you be CADOing or ggnfs-16e? If cado, I will likely test larger LPs than with ggnfs.

Almost certainly CADO'ing; it's my go-to now. Haven't used the GGNFS sievers for a while.