Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: 2 Interesting Positions

Author: James Robertson

Date: 07:42:48 11/23/99

Go up one level in this thread


On November 22, 1999 at 11:59:02, Ed Schröder wrote:

>On November 22, 1999 at 10:58:25, James Robertson wrote:
>
>>On November 22, 1999 at 06:43:08, Ed Schröder wrote:
>>
>>>>Posted by Peter McKenzie on November 22, 1999 at 03:11:18:
>>>
>>>Hi Peter,
>>>
>>>>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.
>>>
>>>Same here:
>>>
>>>00:00:01  6.00  -0.17   1.Qe3 Rg8 2.Rb8+ Kg7 3.Qg3+ Kh6
>>>                       4.Qe3+ Rg5 5.Bg4 Qxa2 6.Qh3+ Kg7  (1)
>>>
>>>00:00:02  6.23  -0.17   1.Rxe7
>>>00:00:02  6.23  0.00   1.Rxe7 Kxe7 2.Qa7+ Kd8 3.Qb8+ Kd7
>>>                       4.Qa7+ Kd6 5.Qd4+ Kc7  (2)
>>>
>>>00:00:02  7.00  0.00   1.Rxe7 Kxe7 2.Qa7+ Kd8 3.Qb8+ Kd7
>>>                       4.Qa7+ Kd6 5.Qd4+ Kc7  (2)
>>>
>>>>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.
>>>
>>>Solved in Q-search.
>>>
>>>>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.
>>>
>>>Just extend Q-search one ply more in such cases.
>>>
>>>>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.
>>>
>>>Rebel Century:
>>>
>>>00:00:00  4.00  0.63   1.dxc5 axb5 2.cxb6 bxc4 3.bxc4
>>>00:00:00  4.09  0.94   1.Nxd6 Qxd6 2.dxc5 Rxc5 3.Bxc5 Qxc5
>>>                       4.b4 Rxe2 5.Rxe2  (0)
>>>
>>>00:00:00  5.00  1.32   1.Nxd6 Nxb3 2.Qxb3 Qxd6 3.dxc5 Rxc5
>>>                       4.Bxc5 Qxc5  (0)
>>>
>>>Some hints: extend (almost) every recapture. On the horizon: extend one
>>>ply if the side to move has an interesting double attack such as a fork.
>>>
>>>Ed
>>
>>How do you detect such double attacks without killing speed?
>
>The info comes from Rebel's evaluation function.
>
>Ed


Hmm......

>>James
>>
>>>
>>>
>>>>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 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.