Author: Christophe Theron
Date: 19:22:13 11/22/01
Go up one level in this thread
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
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.