Author: Dieter Buerssner
Date: 02:17:41 11/01/01
Go up one level in this thread
On October 30, 2001 at 15:54:06, Robert Hyatt wrote: >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. Here I cannot follow. KRBP vs KRPP would have a significant larger score than KRBKRP, which again would have a larger score than KRBKRPP. >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. Here again, I can't follow. >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... Sorry, I cannot follow your example. KRBP vs. KRPP would of course not be devided by four. I think, there is no disagreement, that one has to avoid to trade away the last pawn. Or, to try to force to trade the last pawn when on the pawn side. I believe several methods will work. Like Simon pointed out, one may see unwanted artifacts, by not giving the eval some chance to try to improve the position. OTOH, in most cases it will be futile anyway. 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.