Polynomial Request Thread - Page 26

VBCurtis · 2013-10-07, 17:56

Why are you using anything other than sec/rel to judge a poly? Isn't the point of finding a good poly to find one that takes less time to perform the factorization?

#5 performs quite a lot faster than #1 or #2. What am I missing here?

Also, as firejuggler pointed out, comparisons are not made vs E-score here- #1 has a 5% higher score, but sieves ~6% faster. However, #5 scores 4% worse than #1 while sieving 4% faster.

jasonp · 2013-10-07, 20:14

If none of the other parameters are changed, then seconds per relation is the correct measure. If you optimize the other parameters (e.g. factor base limits or special-q range) separately for each polynomial, then you have to use the total estimated sieving time.

RichD · 2013-10-07, 21:47

In a perfect world, sec/rel would seem reasonable. There is an overhead in starting each range, something around 15 seconds before the first relation is recorded. That's why it is better to take a few million Qs per core at a time. With the relatively small work units (WU) of NFS@Home I believe debrouxl is trying to balance the trade-off. I usually look for yield ratio to minimize the WUs. (Assuming all other parameters are the same.) Perhaps debrouxl has more to say because he has been doing this longer than me.

wombatman · 2013-10-08, 02:04

New best from my search for the C168:

Code:

polynomial selection complete
R0: -137982521622728045011243408554463
R1: 1339655601011561771
A0: 42456904591149864315136445197306375920560
A1: 30670859550417145194573777446486006
A2: -7650991139046352760036346229
A3: -1045673741543574747132
A4: 146948730229980
A5: 10371600
skew 7295400.25, size 1.914e-016, alpha -7.572, combined = 4.147e-013 rroots = 5

And a 2nd one that's not quite as good:

Code:

# norm 2.121910e-016 alpha -7.656116 e 3.927e-013 rroots 5
skew: 7644763.78
c0: 71758833171721317865765888880885183510775
c1: 49536046266198119164296136514381007
c2: -90590297181877360519419115
c3: -2765515707324151868651
c4: 68394972845396
c5: 10119900
Y0: -138662170971500796224221234208258
Y1: 347372753308990319

debrouxl · 2013-10-08, 05:37

For the C166, #5 did indeed sieve ~13.3% faster than #2, but produced ~14.4% fewer relations on the range of 1K relations, so it's not significantly better or worse.

sashamkrt · 2013-10-08, 06:40

Code:

n: 518759670509518390499884894142825232305789370205934770356684820953606669616234831388561087386018771667622991938328056602692240129084683654895676978808741395629768407883
# norm 2.390778e-016 alpha -7.157296 e 4.234e-013 rroots 5 skew: 19835022.68
c0: -14766991706078551413874024151190708222720
c1: 16481308623853322795154573138777216
c2: 8711799723929349110308763068
c3: 203660963131057337068
c4: -19625244765905
c5: 108528
Y0: -343466912683455792965746434341297
Y1: 550334592933944653

sashamkrt · 2013-10-08, 13:18

Code:

# norm 2.880607e-016 alpha -8.201338 e 4.765e-013 rroots 5
skew: 89100677.43
c0: -27857995650530594214542724173490926656056000
c1: 489092174862742972528340289017184040
c2: 30770925245570759449861491874
c3: -51337377580050003917
c4: -4407409358582
c5: 10200
Y0: -551154318026277087308020573543333
Y1: 109459496504263717

# norm 2.578144e-016 alpha -7.900994 e 4.453e-013 rroots 5
skew: 89152497.21
c0: -25294409365820382440286805545396176373535995
c1: 542383637474412430010304925218961429
c2: 30617383334984154264021694081
c3: -66563245603254143525
c4: -4363140797582
c5: 10200
Y0: -551154317931265040287858120286446
Y1: 109459496504263717

wombatman · 2013-10-08, 14:13

Wow! Very nice finds!

VBCurtis · 2013-10-09, 03:28

Quote:

Originally Posted by debrouxl

For the C166, #5 did indeed sieve ~13.3% faster than #2, but produced ~14.4% fewer relations on the range of 1K relations, so it's not significantly better or worse.

Can you help me understand why you care about how many special-Q you need to search? I believe you're saying #5 will need 14% (or 100/86, which is more than 14%) more special-Q searched in order to produce the required number of relations, but even after taking that extra 14% into account that it will finish 13% faster than #2. The sec/rel is time per relation found, NOT time per special-Q searched. It looks to me like you're confusing the two.

The only time I see this having importance is when we're already stretching a version of the siever, and might run out of special-Q. That's not nearly the case here, is it?

sashamkrt · 2013-10-09, 04:45

Code:

# norm 2.790210e-016 alpha -6.156376 e 4.506e-013 rroots 3
skew: 12473534.14
c0: 516236450022905700097829298234459693015
c1: 1155256345148460315833790376537509
c2: 801505740961731706078779054
c3: 187904124865251487543
c4: -5004361126321
c5: 21240
Y0: -475951112043062447304070700973752
Y1: 167570844707882773

LaurV · 2013-10-09, 06:47

Quote:

Originally Posted by VBCurtis

Can you help me understand ...

He says that in the same period of time, one guy runs 100 meters throwing out into the public one dollar at every 10 meters he runs, and the second guy runs 133 meters (13.3 % faster) but spitting one dollar every 14.6 meters (14.6% slower). At the end, the public collects 10 or 11 dollars from the first guy (depending where the thrown out the first dollar), and 10 or 11 from the second (again, depending on the luck), so there is no relevant comparison between the productivity of the two guys.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
GIMPS wiki account request thread	ixfd64	mersennewiki	169	2018-09-21 05:43
Polynomial Discriminant is n^k for an n-1 degree polynomial	carpetpool	Miscellaneous Math	14	2017-02-18 19:46
Lost Prime Raider password request thread	cheesehead	Forum Feedback	6	2009-07-28 13:02
Polynomial	R.D. Silverman	NFSNET Discussion	13	2005-09-16 20:07
Deutscher Thread (german thread)	TauCeti	NFSNET Discussion	0	2003-12-11 22:12

2013-10-07, 17:56	#276
VBCurtis "Curtis" Feb 2005 Riverside, CA 4,861 Posts	Why are you using anything other than sec/rel to judge a poly? Isn't the point of finding a good poly to find one that takes less time to perform the factorization? #5 performs quite a lot faster than #1 or #2. What am I missing here? Also, as firejuggler pointed out, comparisons are not made vs E-score here- #1 has a 5% higher score, but sieves ~6% faster. However, #5 scores 4% worse than #1 while sieving 4% faster.

2013-10-07, 20:14	#277
jasonp Tribal Bullet Oct 2004 DD5₁₆ Posts	If none of the other parameters are changed, then seconds per relation is the correct measure. If you optimize the other parameters (e.g. factor base limits or special-q range) separately for each polynomial, then you have to use the total estimated sieving time.

2013-10-07, 21:47	#278
RichD Sep 2008 Kansas 2⁴×211 Posts	In a perfect world, sec/rel would seem reasonable. There is an overhead in starting each range, something around 15 seconds before the first relation is recorded. That's why it is better to take a few million Qs per core at a time. With the relatively small work units (WU) of NFS@Home I believe debrouxl is trying to balance the trade-off. I usually look for yield ratio to minimize the WUs. (Assuming all other parameters are the same.) Perhaps debrouxl has more to say because he has been doing this longer than me.

2013-10-08, 05:37	#280
debrouxl Sep 2009 1111010001₂ Posts	For the C166, #5 did indeed sieve ~13.3% faster than #2, but produced ~14.4% fewer relations on the range of 1K relations, so it's not significantly better or worse.

2013-10-08, 14:13	#283
wombatman I moo ablest echo power! May 2013 29×61 Posts	Wow! Very nice finds!