Author: Robert Hyatt
Date: 12:54:06 10/30/01
Go up one level in this thread
On October 30, 2001 at 15:08:30, Dieter Buerssner wrote: >On October 30, 2001 at 13:27:20, Simon Finn wrote: > >>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. > >This is similar to what I am doing in Yace. I don't devide by ten, but rather by >four. It still seems enough, to avoid trading away the last pawn, to get a >probable draw position. Other endgame positions are also interesting. Say KNNKP. >I think, this mostly can be won by NN, but could an engine do it without the >help of TBs? Yace can't ... And Q vs. two minor pieces? However the R+minor >piece vs. R seems to be the most common case in normal games, where this problem >arises. If you go back a few versions in crafty, I did this as well. Perhaps that is where you got the idea. But it _does_ fail. IE you are in a KRBP vs KRPP ending. You have five moves. One keeps you in a KRBP vs KRPP ending but you have to give up the pawn outright. Score = +2, divided by 4 = +.5. The second move trades the pawn away into a KRB vs KRP, score = +2, divided by 4 = +.5. The third option leads to a repetition, score = 0.00. The fourth option lets you sac your bishop for the two pawns of the opponent. Leaving you in a KRP vs KR with a score of +1 if you don't have tablebases. The final option lets you remain in the KRBP vs KRPP with a score of +2.0... which move do you choose? Staying in the KRBP vs KRPP as long as possible, until the 50 move rule looms, and drags the score to 0.00. To avoid that score, which move do you play? The point here is that KRBP vs KRPP might seem to be the same as a KRB vs KRP ending. The KRB has no chance of winning in a real game. There may be a contrived position where the KRB side wins, but I haven't seen any in real games yet myself. I don't want _my_ program to trade from a possiblly winnable KRBP vs KRPP, to a absolutely unwinnable KRB vs KRP ending, if I can help it. My divide-by-four failed in several cases on ICC back some time ago, which led to the change that is now being used... It was changed far enough back that I really don't remember when the score>>2 stuff was deleted. My only comment here is that if anybody doesn't trust what I am doing, by all means don't try it. But at present, it seems to be doing exactly what it is supposed to do, that is preventing my program from letting my opponent sneak into a drawn position that looks winnable. Time will tell if I see any exceptions that require modification of this stuff... and I am sure that I will add to it as time goes on and I find other easy-to-recognize cases to avoid. I.E. I don't do anything with queens right now... but the same thing should apply there although I don't try to catch it at the moment. I have seen Crafty win a piece many times, and then trade until the game is drawn. I wrote the current code to avoid that. I haven't yet seen it win a piece and trade down into a KQB vs KQ for example, although I try to handle this crudely... Which of those do you choose? > >Another nice position: > >[D] 4kr2/R4p2/6p1/8/1K6/3B4/8/8 w - - > >Regards, >Dieter
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.