Author: Peter McKenzie
Date: 00:11:18 11/22/99
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? 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
This page took 0.01 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.