Author: Simon Finn
Date: 10:27:20 10/30/01
Go up one level in this thread
On October 30, 2001 at 11:08:10, Robert Hyatt wrote: >That is the _wrong_ way to look at this. The question is probability. How >many positions in KRB vs KRPP do you think are _won_ for the KRB side? And >how many are not? > >If you believe, as I do, that the vast majority _are_ draws, and this is >provable pretty easily, then I certainly want my program to avoid such a >position if it has the KRB, because it isn't going to win. Suppose Crafty is playing the side with not-very advanced pawns in such a drawn endgame. Its evaluation comes back as 0.0 for any move that doesn't blunder the rook or walk into a quick mate. That means that it has completely lost its positional judgement, and will start playing "random" moves. Meanwhile, its opponent is improving the position of its pieces, perhaps setting up a mating net. How long can Crafty play like this until it falls into a mate that was just over its horizon? You could reduce this "snow-blindness" effect by dividing an unfavourable-for-the-pawns evaluation by (say) 10 rather than simply truncating it to 0. >IE if crafty has a KRBP vs KRPPP, it is _not_ going to trade away that >last pawn to reach a KRB that is most likely drawn. While many programs >will do this (I see this rule kick in with reasonable frequency on ICC). On the other hand, if it has KRBP vs KRBP and an evaluation of -0.1, won't it sacrifice its bishop for the pawn to get a draw score from KRBKRP? Combine that with snow-blindness, and one day it's going to cost you half a point. >When I see an exception that causes it to misevaluate and lose, I certainly >modify the code to recognize the exception. But so far, it hasn't happened >that I have seen. > >It is very difficult to make evaluations 100% perfect, which is getting >overlooked here. IE most programs are probably under 75% in evaluating >king safety correctly. That is going to have a much more significant >effect on how the program does than this simple ending heuristic. > >Meanwhile I don't have to suffer through the embarassment of seeing my >program trade into a KRB vs KR with an evaluation of +3, or into a KRB >vs KRPP with an evaluation of +1. Particularly when _before_ the trade >it really _was_ winning. The divide-by-ten version of the heuristic would also avoid this embarassment. > >If you strive for 100% accuracy, you are doomed to failure from the beginning, >until your program can search to a forced mate from the starting position. I >haven't suggested that anyone copy this rule if they don't want to. I didn't >suggest that anyone copy the bishop trapped at a7/h7 stuff either, but when I >first did it, I busted most every program around with that trap, over and >over, until they decided it was time to fix it too. And I can show you >exceptions where the rule doesn't work. But they are rare enough that the >risk of mis-evaluating is much lower than the risk of not evaluating that at >all.. Simon
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.