Author: Matthew White
Date: 15:57:12 02/03/04
Go up one level in this thread
On February 03, 2004 at 18:26:16, Robert Hyatt wrote: >On February 03, 2004 at 18:11:23, Matthew White wrote: > >>This message is probably directed to Bob. I was reading through the eval code in >>Crafty 19.9, and I noticed the function EvaluateStalemate which only tests for >>stalemate if the side to move has no pawns and no pieces. There are many cases >>when the side to move could have both pawns and pieces on the board and still be >>stalemated. For example, in the following position, white cannot take black's >>queen with Qxf3 because an immediate stalemate results (after Kh4 Qg3 or Qxg4, a >>stalemate is forced anyway). By the way, adding a black bishop on h8, it is >>still a stalemate (see the second diagram). I think that the correct way to >>detect stalemate is the side to move has no legal moves and is not in check. I'm >>guessing that there was some optimization that led to this code, but it causes >>Crafty to miss out on draws by stalemate in some hopeless positions. >>Incidentally, the position that brought about the stalemate defense is included >>as the third diagram (from Gelfand-Kramnik, Candidates Match Game 6 1994). The >>key move is 67... Qc1! because Qxd8 leads to rapid stalemate. Gelfand played 68. >>d5 in the actual game, but still only drew. > >Note that the code is only used for one purpose... > >To handle the problems that occur in certain types of drawn positions that get >evaluated wrongly. All I care about is a lone king that has no moves, >primarily, as it wrecks a few special-case evaluations I do such as bishop + rp. >It is not intended to catch all stalemates, that is the purpose of the search. >In general, if one side has been stalemated, then the search would have already >found it and returned the right score. This just prevents thinking one side can >win an ending if the other king can not move, in special cases... > > > > >> >>[D]3Q4/4R1pk/p4p1p/P4P1P/3P2P1/5qK1/8/8 w - - 0 4 >> >>Crafty happily takes the queen though, and a stalemate results. > >This has nothing to do with the stalemate evaluation code. This is a result of >the searching deciding that a draw is the best score it can produce. IE comment >the code out and try it. Nothing will change. The main intent here is to >catch the case of (say) king + bishop + right rook pawn that is not a win if the >opponent king has been stalemated in the position being evaluated... Ahh, okay, so it doesn't try to take the slowest path to draw if it is up material? > >>White(3): go >> clearing hash tables >> time surplus 19.76 time limit 30.34 (3:32) [easy move] >> depth time score variation (1) >> 15-> 0.16 0.01 3. Kxf3 >> 16 0.16 0.01 3. Kxf3 >> 16-> 0.24 0.01 3. Kxf3 >> 17 0.24 0.01 3. Kxf3 >> 17-> 0.35 0.01 3. Kxf3 >> 18 0.35 0.01 3. Kxf3 >> 18-> 0.58 0.01 3. Kxf3 >> 19 0.58 0.01 3. Kxf3 >> 19-> 0.96 0.01 3. Kxf3 >> 20 0.96 0.01 3. Kxf3 >> 20-> 1.66 0.01 3. Kxf3 >> 21 1.66 0.01 3. Kxf3 >> 21-> 3.57 0.01 3. Kxf3 >> 22 3.57 0.01 3. Kxf3 >> 22-> 7.46 0.01 3. Kxf3 >> 23 7.46 0.01 3. Kxf3 >> 23-> 26.47 0.01 3. Kxf3 >> 24 26.47 0.01 3. Kxf3 >> time=49.63 cpu=388% mat=6 n=108272028 fh=87% nps=2.18M >> ext-> chk=14554635 cap=169258 pp=210432 1rep=876371 mate=112511 >> predicted=1 nodes=108272028 evals=29355913 >> endgame tablebase-> probes=0 hits=0 >> hashing-> 34%(raw) 33%(depth) 99%(sat) 99%(pawn) >> hashing-> 0%(exact) 30%(lower) 3%(upper) >> SMP-> split=22850 stop=3198 data=16/128 cpu=3:12 elap=49.63 >> >>White(3): Kxf3 >> time used: 49.63 >> puzzling over a move to ponder. >> clearing hash tables >> depth time score variation >> (no moves) >>Stalemate with a bishop on board: >>[D]3Q3b/4R1pk/p4p1p/P4P1P/3P2P1/5K2/8/8 b - - 0 2 >>The original position (key move is Qc1!): >>[D]2qr4/4R1pk/pQ3p1p/P4P1P/3P2P1/5P1K/8/8 b - - 0 1
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.