Author: José Carlos
Date: 00:02:29 11/23/01
Go up one level in this thread
On November 22, 2001 at 22:22:13, Christophe Theron wrote: >On November 22, 2001 at 21:34:38, Gareth McCaughan wrote: > >>On November 22, 2001 at 17:56:07, Colin Frayn wrote: >> >>> I've been looking at static endgame evals again (i.e. no searching). >>> >>> I'm not sure how 18.12 manages, but Crafty 18.10 completely misevaluates >>> this simple endgame position. So does the current build of Beowulf. >>> It's obviously a win for white, but yet both engines evaluate >>> this position as a massive advantage to black. >>> >>>[D]8/1KPk4/8/6p1/p7/8/8/8 b - - >> >>Think for a moment about how *you* evaluate this position as >>"obviously a win for white". I bet the answer is that you >>think "White will just push the pawn and queen; Black can't >>take it". In other words, you do it by looking ahead: by >>search. Why shouldn't programs do likewise? >> >>I think most programs will look ahead one move "for free" >>in this position as a result of pawn-push extensions, so >>it's not as if they'll misevaluate something upstream by >>stopping searching in the diagram position. So the only >>reason for catching this in the static eval would be to >>save execution time. That's a valid reason, but you have >>to ask whether the time it saves is worth the time it >>costs. It might well be, but I wouldn't make a large bet >>on it. >> >>-- >>g > > > >You are right and that's why Shannon found as early as 1949 that a chess program >should only evaluate "quiet" positions. > >A simple definition of "quiet" is that a position is not quiet if one side is in >check, one side has a winning capture, or one side can promote. > >This has been simplified even more in most chess programs, which consider that a >position is not quiet is the side TO MOVE is in check, has a winning capture or >can promote. > >In order to avoid evaluating "quiet" positions, a "quiescence search" is done by >the programs when they have reached the target depth. The quiescence search will >try at least the out-of-check moves, the captures and the promotions. > >So almost no program will evaluate the first position above and return this >evaluation as the value of the node. Instead, they will first try the promotion >and see what happens. They won't even return the evaluation after white has >promoted, because black is in check then! > >When you design an evaluation function you need to take this into account: is >the class of positions I want to evaluate a class of "quiet" positions? If not, >you do not even need to care about that class of positions. > >For example, an evaluation function of a "classic" chess program should not care >about the case where the side to move can promote. So you can save the work of >trying to guess if the promotion is possible, legal, or even worth it. > >However you have to evaluate the value of the potential promotion when the side >not to move can promote (but that's a different thing). > >That's also why most chess programs do not recognize checkmate in their >evaluations. A checkmate position is not "quiet" (one side is in check). > > > > Christophe I think Colin is right after all. In the given position it's black to move, so if you find it in quiesce you'll always return the static eval which, in this case is black is winning. You won't understan white wins until this position if found in the regular search. Shouldn't be a big problem, but you could miss it if your root position has some pieces you could eventually exchange to reach this position. José C.
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.