Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Search and eval in the endgame

Author: Tord Romstad

Date: 11:44:48 01/05/04

Go up one level in this thread


On January 04, 2004 at 14:24:51, Richard Pijl wrote:

>On January 04, 2004 at 14:03:08, Tord Romstad wrote:
>
>>After playing through countless games by my own and other amateur engines in
>>various
>>tournaments the last half year, I have noticed that a very big percentage of the
>>games are
>>decided in the endgame, where most engines (my own is no exception) are so
>>clueless
>>that it is painful to watch.  I've decided to try to improve my engine's play in
>>this phase
>>of the game, but unfortunately I've found that it is by no means easy.
>
>I've seen many obviously (for humans) drawn endgames go to a win for the endgame
>specialists, and even lost endgames are sometimes turned into a win. Adding
>better endgame capabilities certainly pays off.

Absolutely.  It seems to be the most neglected area in most chess engines
(at least in weak amateur engines around Gothmog's level).

>>First of all, I have difficulties making my search efficient in the endgame.
>>Most of the
>>pruning tricks that work in the middlegame don't work very well in the endgame.
>>I've
>>tried knowledge-based forward pruning, several variants of futility pruning,
>>multi-ProbCut, multi-cut, and my usual techniques of extending and reducing
>>moves
>>depending on how they affect the components of the evaluation funciton.  Another
>>idea I have experimented with is to include passed pawn pushes in the qsearch in
>>pawn endgames.
>
>Try adding more specific evaluation first. That will help building smaller
>search trees too. First step would be to recognize specific drawn endgames, like
>krpkrn (under certain conditions of course :).

I suppose this is the way to go, but I really don't want to write specific
code for all sorts of endgames.  I would prefer to keep my code as simple
and general as possible, partly for aesthetical reasons, and partly because
all the special cases increase the code size (which is very important to
me, because my main goal is to port my engine to PalmOS).

But still, I will probably add specific code at least for the most simple
and common endgames.  I already have special evaluation functions for
kpk, krkb, krkn, krbkr and a few other basic endgames.

>Second would be evaluation of pawnraces, also the complex cases. You'll see wins
>many plies of search earlier! It will take quite a while before getting that one
>right though.

This is clearly very important, but tricky to get right, and even small
bugs can have catastrophic consequences.

>Baron searches relatively deep compared to some other engines in the endgame.

So does Gothmog, although I really don't understand why.  An educated
guess is that the average change in score between two iterations is
smaller in the endgame, and that this makes MTD(f) more efficient.  I
have no idea whether this is the correct explanation, though.

>This has only little to do with pruning. Baron only uses (double) nullmove. When
>one side has a knight or less it doesn't do nullmove at all ...

Very similar to my own endgame search, then.  I also avoid nullmoves at
nodes where the evaluation function decides that the danger of zugzwang
is big (the decision is based on material and safe mobility).

Thanks for your suggestions!

Tord



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.