Author: Will Singleton
Date: 11:48:09 11/22/99
Go up one level in this thread
On November 22, 1999 at 03:11:18, Peter McKenzie wrote: >Greetings, >Here are a couple of interesting positions to try on your favourite programs. > >Positon 1 >The first position comes from the game DarkThought-LambChop at the 1999 WCCC in >Paderborn. Lambchop had an advantage but went astray by allowing a perpetual >check. Here is the position: > >5k1r/1R2bp1p/2p1pp2/7B/8/8/P1q3PP/6QK w - - > >DarkThought, which must have seen the draw several ply earlier, played Rxe7 >which forces the draw (after Kxe7 Qa7+ etc). I tried this position on Chop, >which needed a whole 11ply to see that Rxe7 draws. I mentioned this position in >channel 64 on ICC, and Bob said that Crafty only needs 6ply. > >I asked Bob if he was doing any fancy stuff in search to see perpetuals faster, >but he said he wasn't. Oh well, maybe I have a bug I thought. But looking at >the position, its obvious the drawing line is longer than 6ply. The black king >can go to d6,c7,c8,d7,d8: quite a number of squares to walk around. > >Then it struck me why Crafty saw it so fast. Anytime the black king got to the >back rant, Crafty would see Qa8+ followed by Qxh8 winning a rook for white. >Then it would hit the qsearch (or nullmove and hit the qsearch) where black has >no good capture. The difference being that LambChop (which looks at checks in >the qsearch) would hit the qsearch, and see Qb1+ forces checkmate. > >So here is a position where Crafty very quickly gets the right move and >evaluation, but for the 'wrong reasons'. Bob informs me that this is called the >'inverse horizon effect' :-) > >So how do other programs do on this position? > I allow 1-2 checks in the qsearch, but get it in 6 ply: ply score time nodes n/s pv 2 -23 0.01 1490 89400 3 -90 0.23 2026 5280 Rb8 Kg7 Rb7 Qf5 3 -88 0.24 2391 5940 Ra7 Rg8 a4 3 -86 0.25 2924 6960 Bf3 Qxa2 Bxc6 Rg8 3 -36 0.28 4493 9600 Qe1 f5 Qa1 3 -29 0.29 5393 11100 Qe3 Qf5 Rb8 Kg7 Qg3 Qg5 4 -29 0.31 6706 12960 Qe3 Qf5 Rb8 Kg7 Qg3 Qg5 5 -70 0.46 17761 23160 Qe3 Rg8 Qh6 Ke8 Bf3 Bd6 6 -137 1.32 59123 38520 Qe3 Qxa2 Rb8 Kg7 Qg3 Kh6 Qe3 Kxh5 Rxh8 6 -100 2.10 93946 43320 Rb8 Kg7 Rxh8 Kxh8 6 -99 2.24 106898 44520 Qe1 Rg8 6 0 3.27 165591 47940 Rxe7 Kxe7 Qa7 Kd6 Qd4 Kc7 Qa7 Kd6 >Position 2 >This one happened in a blitz game Ferret-LambChop on ICC: > >2r1r2k/1p1q1ppp/pn1p1b2/nNp2b2/2PP4/PP2BN2/Q3BPPP/2R1R1K1 w - - 0 18 > >Ferret played the crushing Nxd6 which works because white has not one but two >pawn forks coming up. The main line being: >Nxd6 Qxd6 dxc5 Rxc5 Bxc5 Qxc5 b4, a 7ply line. But of course, the normal >horizon effect kicks in so LambChop will then think Rxe2 Qxe2 helps before >'realising' the pawn fork is still there. > >So Lambchop needs 9ply, and around 2min and 1.2M nodes on my P133 to see this >little combination. A bit slow for my liking! How does your favourite program >do?? > >In days gone by, I might have seen it faster due to the recapture extension but >these days I try to limit that extension much more so it doesn't help here. >Other programs might do some static analysis of the pawn fork to see this one >faster. I guess you could include that sort of thing in your evaluation, or >perhaps base some sort of extension on it. I think GNUChess had some hung piece >code to deal with this sort of thing. I'd be interested in hearing any thoughts >from fellow programmers on this issue. > >cheers, >Peter I do recaptures, but it also takes me 9 ply. I had some special fork stuff in there, but it doesn't seem to help here. I'll look at this more. How did chop do on that endgame position I posted a while back? Will
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.