Author: Robert Hyatt
Date: 12:40:54 10/30/01
Go up one level in this thread
On October 30, 2001 at 13:27:20, Simon Finn wrote: >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. Nope. You didn't understand. In a KRB vs KRPP ending, the position is evaluated as "white can't win, black can". If the pawns are not advanced then the score will be latched to zero. But if the pawns can advance (and two connected passers don't have to be advanced very far to offset that piece) then the score can swing negative. It is _very_ difficult to walk into a mate in a KRB or KRN vs KRPP ending. Those "mating nets" are nearly impossible to create... > >How long can Crafty play like this until it falls into a mate that >was just over its horizon? > In KRB/N vs KRPP it can play a _long_ time as there are hardly any mates in the position. And if the pawns are advanced and the usual endgame heuristics are being used, mates are impossible to create with the king in the center of the board and the rook on a reasonable square... >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. I used to do that. I didn't particularly like the result, because then the KRB side can actually think that entering a KRB vs KRPP ending is not dead drawn, when it really can't win such an ending regardless of what the score says... > >>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. if it does that it will almost certainly end in a draw. The KRB vs KRP is _not_ going to be lost. And in the meantime, it is going to save me a _lot_ of 0 scores, because my opponents think that KRB vs KRP is winning for the KRB. When it isn't. > >>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. > Not as well. KRB vs KRPP should be roughly +1.0. Or +.1 if divided by 10. That still looks better than a real draw. Yet it isn't. >> >>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 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.