Author: Ricardo Gibert
Date: 02:29:23 01/20/01
Go up one level in this thread
On January 20, 2001 at 00:17:26, Robert Hyatt wrote: >On January 19, 2001 at 21:51:09, Uri Blass wrote: > >>On January 19, 2001 at 21:33:08, John Merlino wrote: >> >>>On January 19, 2001 at 17:23:03, Scott Gasch wrote: >>> >>>>Hi all, >>>> >>>>Here's a pretty simple test position. This comes from the WAC suite... my >>>>engine does fairly well on this suite as a whole but seems blind to this >>>>solution. >>>> >>>>[D]8/7p/5k2/5p2/p1p2P2/Pr1pPK2/1P1R3P/8 b - - >>>> >>>>The solution is Rxb2 -- black's connected passers are unstoppable after the >>>>recapture. >>>> >>>>My program refuses to find this solution... even at 9 ply it misses it. The >>>>strange thing is that from the other side after Rxb2 it sees that white is toast >>>>very quickly... score dropping to -500 or so after about 1 second. >>>> >>>>My question is, of course, how this move is missed. I've tried kicking up the >>>>value of connected passers and passed pawns in general. I've tried adding a >>>>special rule to eval about connected passers on the 7th, on move, with control >>>>of a queening square. I've tried cutting back my futility margin in qsearch and >>>>always extending a full ply for checks (It usually extends only 3/4 ply for >>>>checks after the iteration depth). And still it does not find Rxb2. >>>> >>>>Even stranger is if I run a static eval with the two connected passers rolling >>>>towards the queening square after the rook exchange the eval puts black ahead! >>>>I can't seem to figure this out... either my pruning is too aggressive or there >>>>is some other bug in the engine...? >>>> >>>>I hope someone out there can give me a little advice. Thanks! >>>> >>>>Scott >>> >>>Just to make things difficult, Chessmaster 8000 seems to have this one's number, >>>AND it reports the correct move at ply 9, despite other postings here that have >>>stated that it should take somewhere between 12 and 14 plies to find the result. >> >>You are right and it is also clear from the main line that it can see the queen >>on the board and does not solve it for wrong positional reasons that vincent >>suggests. >> >>Uri > > >I would disagree with Vincent's reasoning. Crafty solves it for the _right_ >positional reasons before it sees the tactical win. It notes that the king >can't stop the pawns, and it _knows_ that a rook can't stop them. Hence this >is the _right_ reason here... even without seeing deep enough to see the >actual promotion. It only takes crafty a few seconds to see the actual >promotion so it is really moot... but to say that at 8 plies it solves it for >the wrong reasons is a stretch at least. ie if you have a rook, I have two >connected passers on the 7th, and your king is too far away to help, I am going But Whites King is not too far away! It is obstructed by the e-pawn. Without the e-pawn, the King is just in time. White loses due to the connected passed pawns *plus* obstruction of its King. Unless your eval handles connected passed *and* obstruction correctly, Crafty must solve it by searching a bit deeper. If it is not doing that, it is guessing. >to get a queen and there is nothing you can do about it. Whether my eval >recognizes that, or I have to wait for the search to recognize it doesn't >matter. the pawns are going to win...
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.