Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: 2 Interesting Positions

Author: Eugenio Castillo

Date: 01:35:13 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?
>
>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.

Eugen 7.7 needs 9ply for first position (about 6 million nodes; draw by checks
are not nice improved) and 4ply for second position (76000 nodes).

Cheers,

Eugenio.



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.