2+ table - Page 10

R.D. Silverman · 2010-01-13, 15:34

Quote:

Originally Posted by R.D. Silverman

Here is 2,1128+ c200 = p84.p117

p84 = 138283721500695845774122794906574976887904939982079412885536147948742638438410963841
p117 = 331453886037735990099589660143150710637330532262365993616318946009091618610199434701023623302234249752568644578155489

2,1149- is about 70% sieved. I will do 2,1161+ next.
Please reserve it for me.

Bob

I am having one of "those" months. Compiler bugs. A variety of other
'small' nuisances. Now:

I thought I had finished sieving 2,1161+. I ran a filtering pass, and behold:

I found that primes in relations did not divide the norms.

Why?

Because I have silly putty for brains and made a stupid typo in the
sieving intput files. Instead of factoring M^6 - M^3 + 1 with M = 2^129,
I actually did the sieving with M = 2^129 + 1.

Ooops! I have to redo the WHOLE THING.

frmky · 2010-01-13, 19:10

Quote:

Originally Posted by R.D. Silverman

Ooops! I have to redo the WHOLE THING.

Right now add a check that b^d f(a/b) mod N is 0 to the top of your lattice sieve code. Taking a few milliseconds at the beginning of every run sure beats this!

R.D. Silverman · 2010-01-13, 20:21

Quote:

Originally Posted by frmky

Right now add a check that b^d f(a/b) mod N is 0 to the top of your lattice sieve code. Taking a few milliseconds at the beginning of every run sure beats this!

Yep! Except it would not have helped. The linear polynomial
was x - M, and M itself was mis-specified.

frmky · 2010-01-13, 20:27

Quote:

Originally Posted by R.D. Silverman

Yep! Except it would not have helped. The linear polynomial
was x - M, and M itself was mis-specified.

In that case, it just becomes f(M) mod N, and if M is wrong this won't be 0.

R.D. Silverman · 2010-01-14, 12:53

Quote:

Originally Posted by frmky

In that case, it just becomes f(M) mod N, and if M is wrong this won't be 0.

Not quite.. The *other* polynomial mod N won't be 0.
If f(x) = x - M, then (trivially!) f(M) = 0 over Q, over Z, over C,
over z/N, over hill, over dale, etc.

frmky · 2010-01-14, 18:18

Quote:

Originally Posted by R.D. Silverman

Not quite.. The *other* polynomial mod N won't be 0.
If f(x) = x - M, then (trivially!) f(M) = 0 over Q, over Z, over C,
over z/N, over hill, over dale, etc.

Yes, with f(x) = x - M, then f(M) = 0 mod N trivially. But also with f(x) = x^6 - x^3 + 1 and M = 2^129, f(M) = 0 mod N. However, change M to 2^129+1 and f(M) = 875...256 (195 digits) mod N

Batalov · 2010-02-17, 20:22

Quote:

Originally Posted by R.D. Silverman

Consider 2,980+ (currently C162)

We might do it by GNFS (C162) , or we might do it by SNFS with a quartic
(C237), or we might ignore the factor of 5 and doit it via a sextic using
the factor of 7.

A C237 with a quartic will be very slow. It is distinctly sub-optimal.
OTOH, the SNFS/GNFS ratio would be .69 -- a toss-up except for the
quartic.

The sextic would be a C253 and the SNFS/GNFS ratio would be .64,
suggesting GNFS, but perhaps not strongly so.

This might be the first Cunningham number for which we have 3 alternative
and reasonable choices for doing it. GNFS appears to be the winner,
but it is somewhat close.

Indeed, agreed. And as a GNFS, it was now done. Quartics are horrible above diff.230.

p76=1463098735252025076064552980991019750718115268401264794574977849375291943201
p87 cofactor

msieve (CPU version) generates excellent polys for this range of gnfs in about a day on 4cores (I am generalizing from 8 polynomials for size c161-167 so far), so poly generation is not quite a problem it used to be before msieve -np.

Batalov+Dodson gnfs

bdodson · 2010-02-22, 17:47

Quote:

Originally Posted by Batalov

Indeed, agreed. And as a GNFS, it was now done. Quartics are horrible above diff.230.

p76=1463098735252025076064552980991019750718115268401264794574977849375291943201
p87 cofactor ...

Aniruddha and Sylvain report a new p58,

Code:

5007861129737749849013925511829197666405121545507799101441

from 2, 1195+ leaving a c179. I only ran 2t50 in this range (c234-c249.99);
so the cofactor isn't ready for sieving yet. I'm not saying I expect another
factor in ecm range; just reporting that p53/p54's are not sufficiently ruled
out. -Bruce

frmky · 2010-03-05, 21:50

2,887+ is factored. It was a routine SNFS. The log is attached.

83-digit prime factor:
49981689150360109816756745979781091880139282301753764022781406685533122634863077113

124-digit prime factor:
4178064153173557043236151737185710825140844268858730971444861909899441377093367286340227580593337764817973960547233521180267

Batalov · 2010-03-10, 01:26

Quote:

Originally Posted by Batalov

Quote:

Originally Posted by Raman

What about that for (say) 2,956+
$4x^6+1$ with $x=2^{159}$ or that
$x^6+16$ with $x=2^{160}$ upon the other side only?

What about it? It is a gnfs number.

The gnfs/snfs "ratio" is a tricky thing (at this size the break-even should be about 0.665), but for a ballpark I didn't use the ratio but the updated decision equation
gnfs-size <=> snfs-diff * 0.56 + 30

So, to be certain I ran the selection for a short time and I have a weak gnfs poly which is already better than 4x^6+1 (which in turn is better than x^6+16; results not shown):

Code:

n: 1332203900608590809938480645779084229713406802212647383719972524986911760145731133592887032687895490700549453758482415452796437240091528083264268919532584204888670812466960924609380670193
# norm 9.835529e-19 alpha -6.518792 e 1.590e-14
skew: 541811641.32
c0: -801071962246439739537355089135578940272386191585
c1: -42660844449690813403809072437025393127519
c2:  119589890395417785134597484922708
c3:  549962789064608723669511
c4: -240655153909767
c5:  134700
Y0: -1581395993668939777858809095988648046
Y1:  134289229477848734261
type: gnfs
# The lims are off the top of my head
rlim: 268435455
alim: 268435455
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.6
alambda: 2.6

Code:

n: 1332203900608590809938480645779084229713406802212647383719972524986911760145731133592887032687895490700549453758482415452796437240091528083264268919532584204888670812466960924609380670193
Y0: -730750818665451459101842416358141509827966271488
Y1: 1
c6: 4
c0: 1
skew: 0.79
# size 4.489791e-14, alpha 1.946683, e 1.081e-14
type: snfs
lss: 1
rlim: 268435455
alim: 268435455
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.6
alambda: 2.6

I am sure there's a 2.5e-14 poly to be found with enough GPU power. Possibly even 2.7e-14. I have a nagging feeling that there was another poly somewhere (in "Now what" thread series, maybe) but I couldn't find it. "956" and "956+" are deemed not specific enough terms by the search engine.

Could be a good number for the forum or for NFS @ Home.

Batalov · 2010-03-27, 18:07

On my old GPU in 1.5 GPU-days I have only found a single smaller flare up to 1.13e-14. But the search space is immense. If I would have found anything, it would have been some tremendous luck.
Tesla 1070s could do wonders for this number. The parameters this area seem not bad (the polynomials are found by GPU and even the slower CPU), but may need additional tweaking before firing up the large guns.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
5+ table	garo	Cunningham Tables	100	2021-01-04 22:36
7+ table	garo	Cunningham Tables	86	2021-01-04 22:35
6+ table	garo	Cunningham Tables	80	2021-01-04 22:33
5- table	garo	Cunningham Tables	82	2020-03-15 21:47
6- table	garo	Cunningham Tables	41	2016-08-04 04:24

2010-03-27, 18:07	#110
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 22405₈ Posts	On my old GPU in 1.5 GPU-days I have only found a single smaller flare up to 1.13e-14. But the search space is immense. If I would have found anything, it would have been some tremendous luck. Tesla 1070s could do wonders for this number. The parameters this area seem not bad (the polynomials are found by GPU and even the slower CPU), but may need additional tweaking before firing up the large guns.