Author: Robert Hyatt
Date: 10:50:27 11/01/01
Go up one level in this thread
On November 01, 2001 at 12:10:15, Uri Blass wrote: >On November 01, 2001 at 11:09:01, Robert Hyatt wrote: > >>On November 01, 2001 at 05:17:41, Dieter Buerssner wrote: >> >>>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. >> >>I would expect KRBP vs KRPP (+2 in material) to be pretty close to >>KRB vs KRP, which is also +2 in material. But the first has some winning >>chances, while the second has none. >> >>I didn't write it very lucidly above, unfortunately. Either too late or >>too early. :) >> >> >> >>> >>>>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. >> >>Materially they are even. Depending on how advanced the pawns are, one could >>be better than the other (KRBP side might like KRBP vs KRPP better than >>it likes KRB vs KRP... or vice-versa). >> >> >> >> >>> >>>>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. >> >> >>That is a standard part of my eval anyway... "When ahead trade pieces but not >>pawns" and "when behind, trade pawns but not pieces". >> >> >> >> >>> >>>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 >> >> >>That is my thinking. I simply want to see a 0.00 score quickly so that I can >>offer or accept draws reasonably. without this eval term, what used to happen >>was that the KRB side would sit around until the KRPP side got the two pawns >>advanced far enough that the score was in the KRPP side's favor. _then_ it >>would sac the bishop for one of the pawns to reach a drawn krp kr ending. But >>it would struggle like crazy to prevent the pawns from advancing, and it would >>end up prolonging the game 30 moves or more. > >I understand the reason for it(tablebases that say draw for KRB vs KR) but I >believe that the best strategy to get practical chances to win in KRB vs KRPP is >simply to capture the pawns even if you get drawn tablebase position. > >I suggested in the past the 0.01 trick to evaluate KRB vs KR as +0.01 for the >bishop when it is not mate and I understand that it is not enough here if the >KRB vs KRPP is evaluated as more than 0.01 > >There is also another problem that the program is not going to know to get >the right KRB vs KR and choose drawn endgames that are easy to defend. > >These problems do not say that my idea was bad because the alternative when the >program does not prefer endgame with material advantage may be even worse. > > >Uri your idea about the +.01 / -.01 was a good one. I implemented it right after you suggested it and it works just fine, so that Crafty prefers a drawn KRB vs KR rather than a drawn KR vs KR ending. And "swindle mode" enhances this further bu taking the draw-only moves and searching them with a real tree search to choose the one that looks best without any tablebase probes, to avoid tossing the bishop which would still be a draw... But for real play, I _do_ want to know when I really can't win, so that I can offer draws. So far as I know, most programs on ICC don't accept or offer draws. While mine does both. And I have gotten lots of good comments from the GM and IM players about this. The most important thing is to recognize that KRB vs KR is a draw. And I have seen Crafty use this against other programs very successfully. Most don't know that rule, for some reason, and they might be in a won KRBP vs KRB (same color bishops) and let Crafty sac the bishop for the pawn. I won't call any names, as I hope they don't fix it. :)
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.