call for volunteers: RSA768 polynomial selection - Page 4

Batalov · 2011-04-26, 17:53

After I've sent you my chunk, overnight, these two were found, among others:

Code:

28152 2433318054942868451855 59348574860231999861973541552374022242
28548 2081574749379320822615 59210567327921655077067385512778121094

They go to second stage (but I've lowered the entrance threshold) and produce a poly slightly worse than yours:

Code:

# norm 3.700525e-17 alpha -12.717535 e 3.865e-17 rroots 6
skew: 2215723154.54
c0: -970448320646021694578949129049604330614610062721667730848000
c1: -607988932569976140706327616966599745391523757192640
c2:  5204413519179595844548686880742975397398856
c3: -957395753955967142796892206448982
c4: -2284007410820213764514977
c5: -26254608635612
c6:  28152
Y0: -59348575238455548493933386598544474147
Y1:  2433318054942868451855

(both produce 200 polys; one is above, the second only peaks at norm 2.998732e-17 alpha -11.261456 e 3.165e-17 rroots 6). There are some alphas below -13, too.

akruppa · 2011-04-27, 13:12

Running on 5 cpus at the moment; I'll add more as other jobs finish. By when would you like people to submit their results?

Jeff Gilchrist · 2011-04-27, 16:56

I will fire this up on 8 cores, and some GPUs as well. Running in the 90M range for some and probably try 500M for some others just for variety.

Jeff.

jasonp · 2011-04-27, 19:16

Thanks for the extra firepower; give it a month at most.

I should hasten to add that I can be emailed results directly, but try to keep them under 2MB or so. Otherwise you can use sendspace or rapidshare if there's no other private upload space available.

Jeff Gilchrist · 2011-04-27, 23:53

One of my clients is giving a crap line after every poly for one value. The latest selection:

Code:

poly 500170440 564278859499206943266134866747651758733433332176819829531102537646614
crap
poly 500170440 678622847917999215471734866747651758691398744483671458326649864185588
crap
poly 500170440 987491663354360211383934866747651758698994091051914427681031386455062
crap
poly 500170440 633811608938069509018934866747651758617066475863472582786648055154877
crap
poly 500170440 675221726908452533905334866747651758726298637432616667350438814822345
crap
poly 500170440 990676115270466648342734866747651758620947140824681217655780335645732
crap

I should note I'm using the latest SVN take today (svn 563), this is the Windows 64bit CPU build.

The last good line in the .dat.m file is:
500164740 9248931170384508488537 11618305638489772424973270084719459548

Should I just let it keep going and hope it de-crapifies itself or should I kill it and restart after that bad value?

Jeff.

Jeff Gilchrist · 2011-04-28, 00:20

The client de-crapified itself, now working on 500174136 without any crap warnings.

Jeff.

jrk · 2011-04-28, 00:45

Thanks. I'll look at it.

jrk · 2011-04-28, 06:17

Quote:

Originally Posted by Jeff Gilchrist

The client de-crapified itself, now working on 500174136 without any crap warnings.

Jeff.

Please try svn 564 now and see if you continue getting the errors. Thanks.

Jeff Gilchrist · 2011-04-28, 10:20

Quote:

Originally Posted by jasonp

Choose a range that is comfortable for you; I use blocks of 50k or so and that should take a few days. The memory use will be minimal, and it should scale nicely on a single machine.

I started with 50k blocks, on my Intel Q9550 the 4 clients are already done their range after 12-14 hours (500M), on my Core i5 machine they are about 50%-60% through their range (90M).

I guess there is a big difference in speed depending on the range you are searching and what is found?

Jeff Gilchrist · 2011-04-28, 12:04

It is amazing the hashtable size from different 50k runs, 6552 for one, 55104 for another, 41546 for another, and 16367 for another. All taking about the same amount of time to run.

I'm now running svn 564 and will let you know if I see any more crap.

Jeff.

jasonp · 2011-04-28, 12:06

Well, the number of leading coefficients (A6's) searched goes down as the size of those A6's goes up (this optimization is to favor A6 values with lots of small factors, to boost the projective root scores of the resulting polynomials). So there is a time difference based on where in the range you start.

The size of the hashtable depends on the number of 'other' entries computed at the beginning of each A6, and on where in the special-q range the current special-q lies.

2011-04-26, 17:53	#34
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3×7×479 Posts	After I've sent you my chunk, overnight, these two were found, among others: Code: 28152 2433318054942868451855 59348574860231999861973541552374022242 28548 2081574749379320822615 59210567327921655077067385512778121094 They go to second stage (but I've lowered the entrance threshold) and produce a poly slightly worse than yours: Code: # norm 3.700525e-17 alpha -12.717535 e 3.865e-17 rroots 6 skew: 2215723154.54 c0: -970448320646021694578949129049604330614610062721667730848000 c1: -607988932569976140706327616966599745391523757192640 c2: 5204413519179595844548686880742975397398856 c3: -957395753955967142796892206448982 c4: -2284007410820213764514977 c5: -26254608635612 c6: 28152 Y0: -59348575238455548493933386598544474147 Y1: 2433318054942868451855 (both produce 200 polys; one is above, the second only peaks at norm 2.998732e-17 alpha -11.261456 e 3.165e-17 rroots 6). There are some alphas below -13, too. Last fiddled with by Batalov on 2011-04-26 at 18:06 Reason: (forgot that with c6, we need "grep -A10"! lost Y1)

2011-04-27, 23:53	#38
Jeff Gilchrist Jun 2003 Ottawa, Canada 3×17×23 Posts	One of my clients is giving a crap line after every poly for one value. The latest selection: Code: poly 500170440 564278859499206943266134866747651758733433332176819829531102537646614 crap poly 500170440 678622847917999215471734866747651758691398744483671458326649864185588 crap poly 500170440 987491663354360211383934866747651758698994091051914427681031386455062 crap poly 500170440 633811608938069509018934866747651758617066475863472582786648055154877 crap poly 500170440 675221726908452533905334866747651758726298637432616667350438814822345 crap poly 500170440 990676115270466648342734866747651758620947140824681217655780335645732 crap I should note I'm using the latest SVN take today (svn 563), this is the Windows 64bit CPU build. The last good line in the .dat.m file is: 500164740 9248931170384508488537 11618305638489772424973270084719459548 Should I just let it keep going and hope it de-crapifies itself or should I kill it and restart after that bad value? Jeff. Last fiddled with by Jeff Gilchrist on 2011-04-27 at 23:56

2011-04-28, 12:06	#44
jasonp Tribal Bullet Oct 2004 DE3₁₆ Posts	Well, the number of leading coefficients (A6's) searched goes down as the size of those A6's goes up (this optimization is to favor A6 values with lots of small factors, to boost the projective root scores of the resulting polynomials). So there is a time difference based on where in the range you start. The size of the hashtable depends on the number of 'other' entries computed at the beginning of each A6, and on where in the special-q range the current special-q lies. Last fiddled with by jasonp on 2011-04-28 at 12:16

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Polynomial selection	Max0526	NFS@Home	9	2017-05-20 08:57
Improved NFS polynomial selection	jasonp	Operation Kibibit	5	2014-09-07 11:02
Call for volunteers: RSA896	jasonp	Operation Kibibit	134	2013-09-03 22:08
2^877-1 polynomial selection	fivemack	Factoring	47	2009-06-16 00:24
Polynomial selection	CRGreathouse	Factoring	2	2009-05-25 07:55

2011-04-27, 13:12	#35
akruppa "Nancy" Aug 2002 Alexandria 100110100011₂ Posts	Running on 5 cpus at the moment; I'll add more as other jobs finish. By when would you like people to submit their results?

2011-04-27, 16:56	#36
Jeff Gilchrist Jun 2003 Ottawa, Canada 3×17×23 Posts	I will fire this up on 8 cores, and some GPUs as well. Running in the 90M range for some and probably try 500M for some others just for variety. Jeff.

2011-04-27, 19:16	#37
jasonp Tribal Bullet Oct 2004 3²·5·79 Posts	Thanks for the extra firepower; give it a month at most. I should hasten to add that I can be emailed results directly, but try to keep them under 2MB or so. Otherwise you can use sendspace or rapidshare if there's no other private upload space available.

2011-04-28, 00:20	#39
Jeff Gilchrist Jun 2003 Ottawa, Canada 3×17×23 Posts	The client de-crapified itself, now working on 500174136 without any crap warnings. Jeff.

2011-04-28, 00:45	#40
jrk May 2008 3·5·73 Posts	Thanks. I'll look at it.

2011-04-28, 12:04	#43
Jeff Gilchrist Jun 2003 Ottawa, Canada 3×17×23 Posts	It is amazing the hashtable size from different 50k runs, 6552 for one, 55104 for another, 41546 for another, and 16367 for another. All taking about the same amount of time to run. I'm now running svn 564 and will let you know if I see any more crap. Jeff.