Author: Robert Hyatt
Date: 07:51:27 01/21/01
Go up one level in this thread
On January 21, 2001 at 01:22:39, Ricardo Gibert wrote: >On January 20, 2001 at 15:50:04, Robert Hyatt wrote: > >>On January 20, 2001 at 14:20:56, Ricardo Gibert wrote: >> >>>On January 20, 2001 at 10:48:59, Robert Hyatt wrote: >>> >>>>On January 20, 2001 at 05:29:23, Ricardo Gibert wrote: >>>> >>>>>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. >>>>> >>>> >>>>Unless I have broken something without knowing, it doesn't "guess". It simply >>>>asks "can the king reach the queening squares in time. And it uses some bitmap >>>>trickery to answer this, which also happens to detect the interference caused >>>>by its own pawn. >>> >>>Even if it does detect the "interference" of the e-pawn, your program must still >>>search, since in a similar position, the e-pawn might be able to move out of the >>>way with check and allow the White King to defend in time. >> >>That is why this is done at _endpoints_ after a decent search, rather than >>in lieu of a search. The search is supposed to clear up the tactics so that >>the eval can accurately decide who is winning... > >That makes perfect sense of course, but just don't claim you're not guessing. >All chess playing programs guess and if they are good guesses, the program will >play well. In that context, then, the word "guessing" is the wrong word. Because _all_ evaluation terms are "guesses" in that context. IE set up a position that is a mate in 3 for white, with black ahead by a queen, and ask _any_ program to give you the static eval with no search. They will all "guess" black is winning because the evaluation does _not_ detect mate in 3. We depend on the search to give the eval "quiet" positions. If you use the eval _without_ the search, then of course you will get wrong answers. > >> >> >>> >>>> >>>>I simply ask "how many moves to reach square X"? I'll look to be sure that >>>>has not been broken somehow... >>>> >>>> >>>> >>>> >>>>>>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 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.