Author: Vincent Diepeveen
Date: 12:53:17 12/30/03
Go up one level in this thread
On December 30, 2003 at 14:57:00, Brian Katz wrote: >On December 30, 2003 at 14:33:19, Vincent Diepeveen wrote: > >>On December 30, 2003 at 14:27:01, Brian Katz wrote: >> >>Brian use the 6 men pawnless for this idiot position and you will >>see a mate much sooner. >> >>>Do any programs out there find mate in less than 80 moves? >>> >>>The winning idea after winning black’s queens, is to corral the Knights, win two >>>of them, and then get into a K+B+B vs K+N 5 piece Tablebase endgame, which in >>>some positions, require at least 74 moves. Perhaps more. >>>If you don't have the 5 piece Tablebases, your program probably will not find >>>mate. You will need at least the 5 piece endgame mentioned above. >>> >>>You may need to set the Tablebase Depth to a setting of 0 rather than the >>>Default setting of 3. >>> >>>[D]n5Kn/8/7k/B6n/8/2B5/2Bq4/4q3 w >>> >>>Analysis by Fritz 8: Tablebase Depth set at 0. >>>Hardware: AMD Athlon XP 2600+ 1 Gig DDR SDRAM >>> >>>1.Bxd2+ Nf4 2.Bxf4+ Kh5 3.Bxe1 Nb6 4.Kxh8 Nd5 5.Bb3 Ne7 6.Beg3 >>> +- (7.22) Depth: 7/12 00:00:00 18kN, tb=45 >>>1.Bxd2+ Nf4 2.Bxf4+ Kh5 3.Bxe1 Nb6 4.Kxh8 Nd5 5.Bb3 Ne7 6.Beg3 >>> +- (7.22) Depth: 8/14 00:00:00 26kN, tb=46 >>>1.Bxd2+ Nf4 2.Bxf4+ Kh5 3.Bxe1 Nb6 4.Kxh8 Nd5 5.Bb3 Ne7 6.Beg3 >>> +- (7.22) Depth: 9/16 00:00:00 42kN, tb=71 >>>1.Bxd2+ Nf4 2.Bxf4+ Kh5 3.Bxe1 Nb6 4.Kxh8 Kg4 5.Be4 Nd5 6.Bxd5 Kxf4 >>> +- (7.22) Depth: 10/21 00:00:00 88kN, tb=220 >>>1.Bxd2+ Nf4 2.Bxf4+ Kh5 3.Bxe1 Nb6 4.Kxh8 Kg4 5.Be4 Nc4 6.Beg3 Kh5 7.Kg7 >>> +- (7.28) Depth: 11/21 00:00:00 197kN, tb=529 >>>1.Bxd2+ Nf4 2.Bxf4+ Kh5 3.Bxe1 Nb6 4.Kxh8 Kg4 5.Bf2 Nd5 6.Bb3 Nc3 7.Be6+ Kf3 >>>8.Be5 >>> +- (7.28) Depth: 12/23 00:00:00 467kN, tb=1594 >>>1.Bxd2+ Nf4 2.Bxf4+ Kh5 3.Bxe1 Nb6 4.Kxh8 Kg4 5.Bf2 Nd5 6.Be5 Kf3 7.Bfd4 Ne3 >>>8.Bd3 >>> +- (7.31) Depth: 13/25 00:00:00 1018kN, tb=4800 >>>1.Bxd2+ Nf4 2.Bxf4+ Kh5 3.Bxe1 Nb6 4.Kxh8 Kg4 5.Bf2 Nd5 6.Be5 Kf3 7.Bfd4 Ne7 >>>8.Bd3 Nd5 >>> +- (7.41) Depth: 14/26 00:00:02 2134kN, tb=11604 >>>1.Bxd2+ Nf4 2.Bxf4+ Kh5 3.Bxe1 Nb6 4.Kxh8 Kg4 5.Bf2 Nd5 6.Be5 Kf3 7.Bfd4 Nb4 >>>8.Bf5 Nd5 9.Kg7 >>> +- (7.44) Depth: 15/29 00:00:04 4887kN, tb=31168 >>>1.Bxd2+ Nf4 2.Bxf4+ Kh5 3.Bxe1 Nb6 4.Kxh8 Kg4 5.Bf2 Nd5 6.Be5 Kf3 7.Bfd4 Nb4 >>>8.Bf5 Nd5 9.Kg7 Nf4 >>> +- (7.50) Depth: 16/29 00:00:09 10238kN, tb=72603 >>>1.Bxd2+ Nf4 2.Bxf4+ Kh5 3.Bxe1 Nb6 4.Kxh8 Kg4 5.Bf2 Nc4 6.Be4 Nb2 7.Bd4 Nc4 >>>8.Kg7 >>> +- (7.56) Depth: 17/32 00:00:25 26904kN, tb=234367 >>>1.Bxd2+! >>> +- (7.84) Depth: 18/33 00:00:34 36314kN, tb=355809 >>>1.Bxd2+! >>> +- (8.13) Depth: 18/35 00:00:54 57493kN, tb=596406 >>>1.Bxd2+ Nf4 2.Bxf4+ Kh5 3.Bxe1 Nb6 4.Ba5 Nd7 5.Kxh8 Nc5 6.Bb6 Nd7 7.Kg7 Kg4 >>> +- (8.16) Depth: 18/35 00:01:02 66117kN, tb=688821 >>>1.Bxd2+! >>> +- (8.44) Depth: 19/37 00:01:09 73772kN, tb=767130 >>>1.Bxd2+! >>> +- (8.72) Depth: 19/37 00:01:10 74411kN, tb=798334 >>>1.Bxd2+! >>> +- (9.28) Depth: 19/37 00:01:12 76918kN, tb=865923 >>>1.Bxd2+ Nf4 2.Bxf4+ Kh5 3.Bxe1 Nb6 4.Ba5 Nc4 5.Kxh8 Kg4 6.Bd1+ Kf5 7.Be2 Nb2 >>>8.Bc1 Na4 9.Ba3 Ke4 10.Bd1 >>> +- (9.59) Depth: 19/40 00:02:17 156703kN, tb=1772123 >>>1.Bxd2+! >>> +- (9.88) Depth: 20/39 00:02:28 168406kN, tb=1892491 >>>1.Bxd2+! >>> +- (10.16) Depth: 20/39 00:02:30 171306kN, tb=1973122 >>>1.Bxd2+ Nf4 2.Bxf4+ Kh5 3.Bxe1 Nb6 4.Ba5 Nc4 5.Kxh8 Kg4 6.Bac7 Kf3 7.Bc1 Ke2 >>> +- (10.22) Depth: 20/39 00:04:10 291849kN, tb=3152989 >>>1.Bxd2+! >>> +- (10.50) Depth: 21/37 00:04:33 317648kN, tb=3419102 >>>1.Bxd2+ Nf4 2.Bxf4+ Kh5 3.Bxe1 Nb6 4.Kxh8 Kg4 5.Ba5 Nc4 6.Bac7 Kf3 7.Bc1 Ke2 >>>8.Be4 >>> +- (10.56) Depth: 21/40 00:09:02 634177kN, tb=7029727 >>>1.Bxd2+! >>> +- (10.84) Depth: 22/39 00:09:45 683693kN, tb=7568689 >>>1.Bxd2+! >>> +- (11.13) Depth: 22/39 00:09:52 691043kN, tb=7790120 >>>1.Bxd2+! >>> +- (11.69) Depth: 22/39 00:09:53 692672kN, tb=7915129 >>>1.Bxd2+ Nf4 2.Bxf4+ Kh5 3.Bxe1 Nb6 4.Kxh8 Kg4 5.Ba5 Nd7 6.Bd8 >>> +- (#80) Depth: 22/42 00:15:05 1096525kN, tb=12784411 >>>1.Bxd2+ Nf4 2.Bxf4+ Kh5 3.Bxe1 Nb6 4.Kxh8 Kg4 5.Ba5 Nd7 6.Bd8 >>> +- (#80) Depth: 22/42 00:15:24 1119467kN, tb=12908527 >>> >>>(Katz, Eatontown 30.12.2003) >>> >>>Brian > >Yes it is an idiot position, but many puzzles are !! >I do not have the 6 piece pawnless Tablebases yet. Still deciding if it is >really worth it. Since I still have a Dial up connection, it would take far too >long to download. >What is your opinion on the need for 6 piece pawnless endings? I would much >prefer to have 6 piece Tablebases involving 1 or more pawns. Such as K+p+p vs >K+N+p or K+p+p+p vs K+R, K+B, or K+N or KPP vs KPP etc. They would be more >practical. > >As far as idiot positions are concerned, how often do you see 6 piece pawnless >endigs come up in real chess?? >Brian You cannot compare computer chess with human chess. But yes i see regurarly 6 men on the board. For example a teammember of mine a year ago had to draw in important game KRPP KR, which he drew. But of course this is at quite a high level. the person in question is fidemaster (Xander Wemmers). This egtb is there nowadays, so for humans this is very nice. I'm busy converting some 6 men egtbs now to my own format. This is win/draw/loss but of course you only care whether a position is a mate or whether it is a draw. For computerchess win/draw/loss is more useful of course as it fits practically at the harddisk. For nalimov the DTM is more important otherwise he cannot publish them, so i understand very well why he uses the DTM and he is excused. My own egtbs are using the compression from Kadatch, superior compression, well done Andrew!). Kadatch is of course also used by Nalimov. Kadatch really did a fine job. It beats zip 2.5 here hands down. really *bigtime*. My own poor huffman experiments are too slow code anyway to use, but if you compare that with the compression that Andrew still achieves then this makes his compression even more impressive. Compression of EGTBs is very important. Without it, just forget using EGTBs. Without superior compression from Andrew, the diep egtb's would be sized all together 5.22 T entries / 5 positions/byte = 1.044 TB You can imagine that despite harddisks getting near that size quickly now, that it is useful to compress this very well! So from your viewpoint seen, downloading diep's egtbs is worth it, but if you plan to download the nalimovs that will be i guess about 2 terabyte all together. Even though i could download many of the 6 men generated by Eugene at 5 MB/s that still took *days* to download. The compression ratio that the 6 men get with pawns is about 3.0 or so, because of all the different mate values which are not so interesting from human viewpoint. Whether you win in 36 moves or 30 really is not so interesting and the 50 move rule really is not a big problem practical spoken. The win/draw/loss of course is much easier to compress. So my w/d/l are already smaller without compression than nalimov with. Though this from scientific publishing viewpoint is not so interesting, practical this is of course very interesting. I'm busy now tuning such to get a better compression for the 6 men. When i have time and money to buy a dual opteron i will be generating a 7 men. That will be a pawnless one though to start with :) Right now the only problem with the egtbs is time. People just count how many points you get in a tournament, no one is interested in whether you can run on a supercomputer or have your own egtb format. Note that in contradiction to what people say the only problem when generating EGTBs is cpu speed, *not* i/o speed. The simple example is that when generating for example white to move mate in 30, your harddisk is easily getting tens of megabytes a second. So say 80MB/s for slow SCSI harddisk (i have U160 at my S2462) that's a mighty 640 million positions a second. The generator however is running at a way slower speed. When test generating some at a quad Xeon 500Mhz, it was getting 500k positions a second a cpu. ...
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.