Work remaining
 

Here is a table of the number of composites remaining in each table. It does not take into account any reserved numbers.

[code]As of 20080905

3-2 9
3+2 14
4-3 1
4+3 3
5-2 0
5+2 2
5-3 0
5+3 1
5-4 0
5+4 1
6-5 0
6+5 0
7-2 0
7+2 0
7-3 0
7+3 0
7-4 0
7+4 0
7-5 0
7+5 0
7-6 0
7+6 0
8-3 0
8+3 0
8-5 0
8+5 0
9-2 0
9+2 0
9-5 0
9+5 0
9-7 0
9+7 0
9-8 0
9+8 0
10-3 4
10+3 5
10-7 5
10+7 4
10-9 5
10+9 4
11-2 3
11+2 8
11-3 6
11+3 9
11-4 3
11+4 8
11-5 7
11+5 10
11-6 2
11+6 10
11-7 2
11+7 8
11-8 7
11+8 5
11-9 5
11+9 7
11-10 4
11+10 4
12-5 6
12+5 10
12-7 5
12+7 10
12-11 5
12+11 13
[/code]

The 10, 11 and 12 tables are loaded into the ECMNET server at 83.143.57.194:8194 and tasks at B1=11M are currently being allocated. It's a fair bet that a good number of factors are still to be found there.

I would suggest that the NFS people concentrate on the other tables and try to clear them. When enough have no remaining composites I will extend the tables, but not before.


Paul

I just noticed something:

[QUOTE=xilman;140993]
There are now 215 composites remaining in the tables, which should be enough to keep you busy for a little while.[/QUOTE]

At [url]http://www.chiark.greenend.org.uk/ucgi/~twomack/homcun.pl[/url][quote]200 numbers available for reservation; 14 reserved[/quote]

Even in my present tired and emotional state I can recognize that 200+14 does not equal 215. There are no unprocessed factors in my mailbox, AFAICT.

Anyone willing to track down the discrepancy? Otherwise it will wait until I have time and ability to do so.


Paul

[quote=xilman;141018]
Anyone willing to track down the discrepancy? Otherwise it will wait until I have time and ability to do so.


Paul[/quote]

I haven't tracked it down, nor will I likely have time to do so, but I did discover something I'll have to be more careful about in the future...

11+5, 169 apparently had an ecm factor found before I reserved it for SNFS. This fact wasn't reflected on the reservation page. The C103 would have been easier by GNFS than the difficulty 162 was by SNFS. Maybe everyone else doing NFS work already knows this, but check the update page before starting work on something.

A clue to the mystery
 

[QUOTE=xilman;141018]I just noticed something:



At [url]http://www.chiark.greenend.org.uk/ucgi/~twomack/homcun.pl[/url]

Even in my present tired and emotional state I can recognize that 200+14 does not equal 215. There are no unprocessed factors in my mailbox, AFAICT.

Anyone willing to track down the discrepancy? Otherwise it will wait until I have time and ability to do so.


Paul[/QUOTE]I have a sordid past. Specifically, concerning 12^199-11^199.

This might not be the time or the place to come clean, but I pulled a 40something-digit factor using ECM, and then accidentally copied the larger composite cofactor into Tom's reservation page. His code saw that the 40something-digit cofactor was prime, so it saw fit to remove the number from the list: all done. Seems he didn't anticipate somebody finding a 169-digit composite factor of a 215-digit integer -- it's reasonable to assume this just won't happen.

I am currently factoring the remaining cofactor of 12^199-11^199.

Some unhelpful attempts to synchronise
 

Hi, Tom here.

I've taken the current comps.gz and found that eight numbers in it aren't present in the reservation server.

[code]
(11+5,172) 2208365198438655038631209293469137329445410402500140159264247306975256867110485490468688897822211579877251025489
(11+5,142) 14202250058465017308306724305927874135253539200597821755545581293957340989056591185066344910310680952424663424317
(11-6,157) 1751330782359719202593070156439936785965370865766076481150475748288990490956716384487835474188969127275151538038627
(12+11,200) 93221843981909261904815552021536096906589400518196687186969467953793619363094646398351539588437338153088175133160401
(10+7,167) 223647331337501130642693578497501842426733748444730351702780813709242741096431450273917668186036117236877146296909317487
(10+9,191) 26288172158544595644139037872912701061670086963602201213252614980370382085927830712956842034458272542638476917837083675927149919
(11+2,151) 950424317584580890001761902392814384698592877781572089656352691779184907970075807452808607682676891755265733768443098299010028639546122985957897643937
(12-11,199) 1246996221337941678791787819171076928189577444047959114400882667484994314595382013298418257505279614270570451318254032344526218442765323509554776679949669312775389149001
[/code]

The underlying bug is that the reservation server doesn't check for primality of submitted factors, whilst it does check for primality of the cofactor, so if you've found an ECM factor and submit the composite cofactor the number got removed from the server.

I have a full transaction log - every modification made to the comps.tab file on the server is logged - but grovelling through it is a bit tiresome.

In my log are the lines

[code]
submitted factor 536235619939567147623761172403456774969913367423090593 for 2208365198438655038631209293469137329445410402500140159264247306975256867110485490468688897822211579877251025489 (11^172+5^172) at 20080811104043
line removed/changed was 2208365198438655038631209293469137329445410402500140159264247306975256867110485490468688897822211579877251025489:11^172+5^172:111.4:179.1:Hugo Platzer:20080810112300:email-redacted:3262

submitted factor 117336807247717742305795997703848105550529659593 for 14202250058465017308306724305927874135253539200597821755545581293957340989056591185066344910310680952424663424317 (11^142+5^142) at 20080418081727
line removed/changed was 14202250058465017308306724305927874135253539200597821755545581293957340989056591185066344910310680952424663424317:11^142+5^142:112.2:147.9:Bob Silverman:20080416151025:email-redacted:9471

submitted factor 501659661107262756178803436251804875808749511715601 for 93221843981909261904815552021536096906589400518196687186969467953793619363094646398351539588437338153088175133160401 (12^200+11^200) at 20080812231410
line removed/changed was 93221843981909261904815552021536096906589400518196687186969467953793619363094646398351539588437338153088175133160401:12^200+11^200:116.1:172.7:Hugo Platzer:20080811200406:email-redacted:7016


submitted factor 902846911135171720653055856748496379488648111561 for 26288172158544595644139037872912701061670086963602201213252614980370382085927830712956842034458272542638476917837083675927149919 (10^191-9^191) at 20080817122410
line removed/changed was 26288172158544595644139037872912701061670086963602201213252614980370382085927830712956842034458272542638476917837083675927149919:10^191-9^191:127.5:191.0:Hugo Platzer:20080813173244:email-redacted:1010

submitted factor 213222874465710420059788387372043912569513827079 for 950424317584580890001761902392814384698592877781572089656352691779184907970075807452808607682676891755265733768443098299010028639546122985957897643937 (11^151+2^151) at 20080817205250
line removed/changed was 950424317584580890001761902392814384698592877781572089656352691779184907970075807452808607682676891755265733768443098299010028639546122985957897643937:11^151+2^151:150.0:157.3:Hugo Platzer:20080811104225:email-redacted:5078

submitted factor 1246996221337941678791787819171076928189577444047959114400882667484994314595382013298418257505279614270570451318254032344526218442765323509554776679949669312775389149001 for 57156805806330488933519373710839286158393712401772493956234280664320580766925259328700676352216286023852934522770263479337721773750336546216714091755144101242431030077076792208434003859416189322310966865655935255357 (12^199-11^199) at 20080715154431
line removed/changed was 57156805806330488933519373710839286158393712401772493956234280664320580766925259328700676352216286023852934522770263479337721773750336546216714091755144101242431030077076792208434003859416189322310966865655935255357:12^199-11^199:214.8:214.8:{FactorEyes}:20080715153335:email-redacted:2750
[/code]

where all the factors except the bottom one are prime.

This removes five lines from comps.gz and leaves everything rather further out of sync; the timestamps are right to within seconds, it's just that Hugo Platzer appears to have put in ECM factors to the reservation server rather than emailing them to xilman, even with the big note about emailing xilman that appears whenever a factor is reported.

Now, numbers in the reservation server which don't appear in comps.gz:

[code]
(12+11,194) 5183071290202406839290860825779129603074482655004883374604031709444454694208520244934541329337165155852071809704613765174667973111530364328364401257
(11-3,173) 6044392620969154898843944929229262529080950862849356638726228846032119673151394122755685397117613417622322330693748720526436081454855540019752146888999
(10+9,194) 5187280146077945770920957254447159530133361422979192881848058551344118674071573379235201791973798544490047011416057971823035871821962611853316293412974915486721
(11+5,163) 2996654743361539643726679959685453201902580027247274369566148519803866714379140664558626520248478390556676326102909371809558723026632541535023715785343278619557509
(11+10,179) 3368080409201765102277262523269405972908237392317512804723919608876335616961403630569506090241989605334285258084770538309866832364101318674528088264150976016679943
(11-6,157) 1233608828974665380850451815465448548111618494286054188455167754588596060628853747592863415464445282954942107294708762026367233213052857917853549179261030293
(10+7,167) 1589085120949479631035410860631392130365919208982352416952680738913391127340849579050957472910499788816359894163195894424692057849484003892941711245973276786373
[/code]

Looking at xilman's tables, I was missing the factors

[code]
214208302104195040523619899128279379458733 of 12^194+11^194
39571397141574620817177824837833199 of 11^173-3^173
226426681913242136679224944428574857229 of 10^194+9^194
266570380156231714887947750037614880365621 of 11^163+5^163
11621979989128275039865688360471467746571759 of 11^179+10^179
704383684338898945704989183073240051681959 of 11^157-6^157 (leaves composite factor)
7105316712013107847714761966973726272779 of 10^167+7^167 (leaves composite factor)
[/code]

I've no idea what the common link between those factors is.

After that fuss, I have 195 unreserved and 14 reserved numbers in the reservation server = 209, and have factors completing five numbers in xilman's tables which reduces that to 210.

When I reinstate 12^199-11^199 and put in the factor 45835588615501292019061467167396681835771062357 found by FactorEyes, I have 195+15 and xilman has 210, and now the numbers match and both sets of discrepancies are explained.

That was tedious. I hope I don't have to do it again any time soon.

I have a new fast computer arriving on roughly Wednesday; as penance for my incompetence in database management, and burn-in for the computer, I'll do the four 5+ numbers. It'll take about a week, I suspect.

5+2.292 done - it took quite a long time because I ended up not running it on the new fast computer. Today's observation: for these rather unbalanced numbers, rational-side sieving of the quintic seems to be the way to go even at difficulty-204:

(sieving 5+3.292, 2^24 .. 2^24+2^12, lpr=lpa=2^24, 29-bit large primes; tsa, tsr are the sextic; tqa, tqr are the quintic)

[code]
tqr total yield: 18245, q=16781327 (0.03739 sec/rel)
tqa total yield: 11218, q=16781327 (0.05693 sec/rel)
tsr total yield: 10585, q=16781327 (0.06181 sec/rel)
tsa total yield: 11274, q=16781327 (0.05420 sec/rel)
[/code]

[quote=fivemack;143632]5+2.292 done - it took quite a long time because I ended up not running it on the new fast computer. Today's observation: for these rather unbalanced numbers, rational-side sieving of the quintic seems to be the way to go even at difficulty-204:

(sieving 5+3.292, 2^24 .. 2^24+2^12, lpr=lpa=2^24, 29-bit large primes; tsa, tsr are the sextic; tqa, tqr are the quintic)

[code]
tqr total yield: 18245, q=16781327 (0.03739 sec/rel)
tqa total yield: 11218, q=16781327 (0.05693 sec/rel)
tsr total yield: 10585, q=16781327 (0.06181 sec/rel)
tsa total yield: 11274, q=16781327 (0.05420 sec/rel)
[/code][/quote]

That's what I've been finding with 3-2.431 and 3+2.439 as well.

[QUOTE=fivemack;143632]5+2.292 done - it took quite a long time because I ended up not running it on the new fast computer. Today's observation: for these rather unbalanced numbers, rational-side sieving of the quintic seems to be the way to go even at difficulty-204:

(sieving 5+3.292, 2^24 .. 2^24+2^12, lpr=lpa=2^24, 29-bit large primes; tsa, tsr are the sextic; tqa, tqr are the quintic)
[/QUOTE]Rational-side sieving is definitely the way to go with these.

I've been happy with 28-bit large primes. I'd use 29 bits for an SNFS 218 or so, but 28 bits has worked well up to SNFS 215. Am I missing out?

Within two weeks, the 4^n and 5^n tables will be complete, as far as they go. It might be fun to clear out most of the remaining 3^n composites. (I'll give the ones above SNFS 230 a pass, though, or maybe collaborate with anyone willing to throw cycles at this low-priority but fun bunch of numbers.)

[quote=FactorEyes;143659]Rational-side sieving is definitely the way to go with these.

I've been happy with 28-bit large primes. I'd use 29 bits for an SNFS 218 or so, but 28 bits has worked well up to SNFS 215. Am I missing out?

Within two weeks, the 4^n and 5^n tables will be complete, as far as they go. It might be fun to clear out most of the remaining 3^n composites. (I'll give the ones above SNFS 230 a pass, though, or maybe collaborate with anyone willing to throw cycles at this low-priority but fun bunch of numbers.)[/quote]

I'm using 29 bit large primes as well, for those 3^n numbers I mentioned. I experimented a bit with 28 vs. 29, and managed to convince myself that 29 was slightly faster. But 3+2.439 is difficulty 210 so it's close to your cutoff point anyway.

I don't want to commit to clearing out the 3,2 composites, but I'm working on several right now and might pick a few more once 5-421 sieving is finished. I'd hesitate to reserve anything above difficultly 220 or so, just because it seems like if I'm going to add that much entropy to the universe, it had better be for a cunningham...

[QUOTE=bsquared;143666]I'm using 29 bit large primes as well, for those 3^n numbers I mentioned. I experimented a bit with 28 vs. 29, and managed to convince myself that 29 was slightly faster. But 3+2.439 is difficulty 210 so it's close to your cutoff point anyway.

I don't want to commit to clearing out the 3,2 composites, but I'm working on several right now and might pick a few more once 5-421 sieving is finished. I'd hesitate to reserve anything above difficultly 220 or so, just because it seems like if I'm going to add that much entropy to the universe, it had better be for a cunningham...[/QUOTE]

I agree; these should be low priority. I am devoting only a single
8-year old machine to them (1.5GHz, 384M of DRAM)