Fast Breeding (guru management) - Page 31

Dubslow · 2015-12-29, 02:40

Quote:

Originally Posted by chris2be8

I can think of quite a few, such as these Oddperfect related numbers in the most wanted list with particularly large weights:
(4051^71-1)/4050
(4091^71-1)/4090

Sadly, I've no idea if they have had enough ECM run against them. And the difficulty is a bit low although the largish coefficients will make them seem harder.

Chris

4051^71-1 (sextic difficulty 260) has been ECMd by yoyo@home, 25K curves at 260M, a bit over half of a t60 (two ninths of 260 is 57.7).

4091^71-1 (sextic difficulty 261) has been ECMd to t55 by yoyo@home, with a similar 25K@260M to be completed in the future.

http://www.rechenkraft.net/yoyo/y_status_ecm.php

fivemack · 2015-12-29, 17:16

4051^71-1 queued at 15e

debrouxl · 2016-01-03, 08:41

The 14e queue should be empty by the end of next week

In the past few weeks, there have been a bunch of largely oversieved numbers, due to sieving being done over the default 20M-100M range, which is usually too wide for 30-bit LPs tasks.
Conversely, some ranges look narrow:
* GW_5_323 and GW_6_292 (30-bit LPs) are being sieved to barely more than 100M raw relations, but it is probably not worth to sieve them further, unless a matrix can't be built;
* 1373_79_minus1 (31-bit LPs) won't reach 200M raw relations, ~10% of those are pending. It could use further sieving, it's not too late. WDYT ?;
* I've moved 1847_71_minus1 (30-bit LPs) back into sieving, as the forecast for the 20M-80M range was below 70M raw relations, which is not enough for building a matrix. The linear projection suggests 118M as the upper bound of the range.

fivemack · 2016-01-03, 11:10

I think there is enough human effort available to make it make sense to start off numbers on a clearly-much-too-short range and then extend the range once the rate is known (at least, in the current circumstances where it seems unlikely that people did pre-sieving to get a reasonable initial rate estimate).

While we have finished numbers waiting for post-processors, there's no particular harm in oversieving, though going to 160M relations for an lp30 number is quite wasteful.

I've moved 1373-79 back to sieving with 20M more Q.

debrouxl · 2016-01-03, 15:55

Quote:

I think there is enough human effort available to make it make sense to start off numbers on a clearly-much-too-short range and then extend the range once the rate is known

Completely agreed, that's what I've been doing for a long time, reducing the default upper bound of 100M on each number.

Greg, could you reduce the default upper bound from 100M to, say, 60M, so that whoever queues and starts numbers has a lower chance of triggering severe oversieving ? TIA

frmky · 2016-01-03, 22:52

Quote:

Originally Posted by debrouxl

Greg, could you reduce the default upper bound from 100M to, say, 60M, so that whoever queues and starts numbers has a lower chance of triggering severe oversieving ? TIA

Done.

swellman · 2016-01-05, 19:26

Here's three low SNFS size that are slow to sieve. ECM'd to t50+. Suggested polys follow.

C221_118_81

C170_119_79

C220_120_79

Code:

n: 32630446320175053998972149659787159917765613388437885789380770221564477802223265901214800455665749623616147693401648453050842883751405065213905870241871731178088325271618545494507514611809953400606891128538932196398974701
# 118^81+81^118, difficulty: 228.06, anorm: 1.13e+032, rnorm: 9.47e+050
# scaled difficulty: 234.72, suggest sieving rational side
type: snfs
size: 228
skew: 5.0194
c5: 1
c0: 3186
Y1: -1412902250550159107801603836542976
Y0: 2120895147045314119491609587512844743630072107
rlim: 31200000
alim: 31200000
lpbr: 30
lpba: 30
mfbr: 59
mfba: 59
rlambda: 2.7
alambda: 2.7

Code:

n: 12501525177655953107237069097070423656186648286176353641202592870476923077573541738039123303976678741906928801754277678640092177768143480162626018754369463410527609806821
type: snfs
size: 227
skew: 4.5940
c6: 1
c0: 9401
Y1: 959644764107166918445086359
Y0: -89648251976843595444986830377401534401
rlim: 31200000
alim: 31200000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.7
alambda: 2.7

Code:

n: 1946141492349742003165748654568733544055934211995020450182588319576709436508484011092836300363057288793274369522685708660813103290223749703935912730543769836340916731087442559922528125706012131538487928342669500511823737
# 120^79+79^120, difficulty: 228.62, anorm: 2.19e+037, rnorm: 8.51e+043
# scaled difficulty: 231.08, suggest sieving rational side
type: snfs
size: 228
skew: 1.1105
c6: 8
c0: 15
Y1: -2139864107581440000000000000
Y0: 89648251976843595444986830377401534401
rlim: 31200000
alim: 31200000
lpbr: 30
lpba: 30
mfbr: 59
mfba: 59
rlambda: 2.7
alambda: 2.7

debrouxl · 2016-01-05, 20:02

Thanks

In the 14e queue, I have expanded ranges for the numbers in the sieving state, but there are currently no numbers queued for sieving. I should queue these ones quickly

swellman · 2016-01-06, 15:41

Here's three more for consideration. Again, low SNFS difficulty with slow sieving characteristics. Polys follow, all sieving in the rational side. ECM'd to t50+.

C197_129_53

C219_127_57

C211_121_75

Code:

n: 29374616055459948615405626071418416350654642253066835805988803274717756855100764057971553648739606773743247670298792705864323704723085550988333113882812815144812699375845207967608041066096911236581
# 129^53+53^129, difficulty: 222.43, anorm: 8.76e+039, rnorm: -6.56e+042
# scaled difficulty: 230.19, suggest sieving rational side
type: snfs
size: 222
skew: 16.3645
c6: 1
c0: 19205133
Y1: -1621038246414954860589967996431649253
Y0: 9892530380752880769
rlim: 26600000
alim: 26600000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.7
alambda: 2.7

Code:

n: 236195267071938897635759035319537563986580167171978212556737082931130388147584351617944739151230665179993823302194517636544393718006097666083450922708633235254957317962682741272241860392466135259166832953844968069052389
type: snfs
size: 223
skew: 1.38
c0: 16129
c5: 3249
Y0: -78862654603529887329150858935314154890152057
Y1: 138624799340320978519423
rlim: 29600000
alim: 29600000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.7
alambda: 2.7

Code:

n: 3943980528012800750768233338889717242809448905805436295581783739277498189605350156945916268220795026108066324184162163750240729469790828053152942637881581612558878938553527602669357197069859798155717838634533483
# 121^75+75^121, difficulty: 230.67, anorm: 1.56e+038, rnorm: 7.87e+043
# scaled difficulty: 234.04, suggest sieving rational side
type: snfs
size: 230
skew: 1.4609
c6: 25
c0: 243
Y1: -108347059433883722041830251
Y0: 95136358168019796721637248992919921875
rlim: 32800000
alim: 32800000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.7
alambda: 2.7

fivemack · 2016-01-06, 16:03

4091^71-1 queued at 15e

debrouxl · 2016-01-06, 18:41

I queued 2*3 XYYXF numbers posted by Sean, and two were just started, by Tom, I guess.

2016-01-05, 20:02	#338
debrouxl Sep 2009 977 Posts	Thanks In the 14e queue, I have expanded ranges for the numbers in the sieving state, but there are currently no numbers queued for sieving. I should queue these ones quickly Last fiddled with by debrouxl on 2016-01-05 at 20:03

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
System management notes	kriesel	kriesel	7	2020-10-21 18:52
Improving the queue management.	debrouxl	NFS@Home	10	2018-05-06 21:05
Script-based Primenet assignment management	ewmayer	Software	3	2017-05-25 04:02
Do normal adults give themselves an allowance? (...to fast or not to fast - there is no question!)	jasong	jasong	35	2016-12-11 00:57
Power Management settings	PrimeCroat	Hardware	3	2004-02-17 19:11

2015-12-29, 17:16	#332
fivemack (loop (#_fork)) Feb 2006 Cambridge, England 1100100011000₂ Posts	4051^71-1 queued at 15e

2016-01-03, 08:41	#333
debrouxl Sep 2009 977 Posts	The 14e queue should be empty by the end of next week In the past few weeks, there have been a bunch of largely oversieved numbers, due to sieving being done over the default 20M-100M range, which is usually too wide for 30-bit LPs tasks. Conversely, some ranges look narrow: * GW_5_323 and GW_6_292 (30-bit LPs) are being sieved to barely more than 100M raw relations, but it is probably not worth to sieve them further, unless a matrix can't be built; * 1373_79_minus1 (31-bit LPs) won't reach 200M raw relations, ~10% of those are pending. It could use further sieving, it's not too late. WDYT ?; * I've moved 1847_71_minus1 (30-bit LPs) back into sieving, as the forecast for the 20M-80M range was below 70M raw relations, which is not enough for building a matrix. The linear projection suggests 118M as the upper bound of the range.

2016-01-03, 11:10	#334
fivemack (loop (#_fork)) Feb 2006 Cambridge, England 2³×11×73 Posts	I think there is enough human effort available to make it make sense to start off numbers on a clearly-much-too-short range and then extend the range once the rate is known (at least, in the current circumstances where it seems unlikely that people did pre-sieving to get a reasonable initial rate estimate). While we have finished numbers waiting for post-processors, there's no particular harm in oversieving, though going to 160M relations for an lp30 number is quite wasteful. I've moved 1373-79 back to sieving with 20M more Q.

2016-01-06, 16:03	#340
fivemack (loop (#_fork)) Feb 2006 Cambridge, England 2³·11·73 Posts	4091^71-1 queued at 15e

2016-01-06, 18:41	#341
debrouxl Sep 2009 977₁₀ Posts	I queued 2*3 XYYXF numbers posted by Sean, and two were just started, by Tom, I guess.