Author: Christophe Theron
Date: 10:46:50 11/23/01
Go up one level in this thread
On November 23, 2001 at 03:02:29, José Carlos wrote:
>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.
I think you should read again my post. A classic chess program will NEVER stop
in the position. Even if it happens very deep in the tree.
Christophe
This page took 0.01 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.