20201219, 00:50  #826  
Apr 2020
2·5·19 Posts 
Quote:
Quote:
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 diff320 without the algebraic factor, but we have to multiply by b in order to use a sextic). Last fiddled with by charybdis on 20201219 at 00:51 

20201219, 01:01  #827  
Just call me Henry
"David"
Sep 2007
Cambridge (GMT/BST)
2·2,909 Posts 
Quote:


20201219, 01:22  #828  
Apr 2020
190_{10} Posts 
Quote:
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 difficulty310 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 sextic335 to get the products equal. This is all guesswork, but I'd be rather surprised if octic301 was faster than sextic320, for example. 

20201219, 01:24  #829 
"Curtis"
Feb 2005
Riverside, CA
2×3×19×41 Posts 
And, since the poly is posted here, I can do that testsieve this weekend, too!
Whether it's similar to sextic310 or 340, we still need a ton of ECM. I agree with the observation that octics will get lessgnarly as difficulty increases by SNFS450 or so, an octic should be faster than a sextic of the same snfsdifficulty! My uneducated guess is that it'll be tractable with 16e, something akin to a sextic at 315320 digits. Edit2: Charybdis, the unbalanced norms suggest looser algside bounds, right? I should testsieve like 33/34 and 33/35, I think. Last fiddled with by VBCurtis on 20201219 at 01:28 Reason: Changed 400 to 450, as the cusp of degree 6 to degree 7 is theoretically 360 digits or so 
20201219, 01:33  #830 
Apr 2020
2·5·19 Posts 
Yes  and sieving and 3LP should be on the algebraic side too of course. Though NFS@home never goes above 33bit large primes I believe?

20201219, 01:38  #831 
"Curtis"
Feb 2005
Riverside, CA
2·3·19·41 Posts 
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). 
20201219, 01:45  #832 
Sep 2008
Kansas
2^{2}×3^{2}×7×13 Posts 
C301
There has already been at least 30K @ 29e8 (if not more) and 10K @ 76e8 on this number.
Last fiddled with by RichD on 20201219 at 01:46 Reason: add title for clarification 
20201219, 01:55  #833  
Apr 2020
276_{8} Posts 
Quote:
Last fiddled with by charybdis on 20201219 at 01:57 

20201219, 02:17  #834  
Jun 2012
Boulder, CO
263_{10} Posts 
Quote:


20201219, 02:49  #835  
"Curtis"
Feb 2005
Riverside, CA
2×3×19×41 Posts 
Quote:
Will you be CADOing or ggnfs16e? If cado, I will likely test larger LPs than with ggnfs. 

20201219, 02:53  #836  
Jun 2012
Boulder, CO
263 Posts 
Quote:
Quote:


Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Passive Pascal  Xyzzy  GPU Computing  1  20170517 20:22 
Tesla P100 — 5.4 DP TeraFLOPS — Pascal  Mark Rose  GPU Computing  52  20160702 12:11 
Nvidia Pascal, a third of DP  firejuggler  GPU Computing  12  20160223 06:55 
Calculating perfect numbers in Pascal  Elhueno  Homework Help  5  20080612 16:37 
Factorization attempt to a c163  a new Odd Perfect Number roadblock  jchein1  Factoring  30  20050530 14:43 