Author: Robert Hyatt
Date: 11:39:02 01/21/01
Go up one level in this thread
On January 21, 2001 at 12:40:41, Ricardo Gibert wrote: >On January 21, 2001 at 10:51:27, Robert Hyatt wrote: > >>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 think it is normal to call a decision a guess when there is a possibility of >being wrong. The trick is to guess well. My use of the term is perfect in this >context. > >Not all evaluations are guesses. There is mate, stalemate, repetition, 50 moves, >insufficient material to mate and EGTB hits in "normal" circumstances. > None of those are "evaluations" at all. Using the term "evaluation" is the value returned by the evaluation code in the chess engine. Mates, etc are all caught by the _search_. Mate scores and so forth are by definition perfect scores, assuming no bugs in the search. But that is the _only_ part of the program that produces 100% accurate scores... The static eval, by definition, is not perfect. If it were, we would not be doing any searching at all... So back to the original idea, if you want to call my 2 connected passed pawns on the 6th term a "guess", then you have to call _every_ term in a static evaluation a "guess". Which means what I have done is nothing unusual at all... >> >> >> >>> >>>> >>>> >>>>> >>>>>> >>>>>>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.