Author: Richard Pijl
Date: 14:25:57 01/04/04
Go up one level in this thread
On January 04, 2004 at 16:37:27, Bob Durrett wrote: >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. >> >>>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 :). >>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. >>Baron searches relatively deep compared to some other engines in the endgame. >>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 ... >>Richard. >> >>> >>>So far, I haven't found a single idea which works. My search in the endgame is >>>a >>>brute-force MTD(f) search with recursive null move pruning with a low reduction >>>factor (R=2 or 1 at most nodes). This is terribly inefficient, and I hope to >>>find >>>something better. Chess Genius seems to do something really clever and >>>effective, >>>but I haven't been able to figure out what it is. Does anybody else have some >>>tricks >>>to share? >>> >>>Endgame evaluation is also tricky, because the evaluation should be very >>>different >>>depending on the type of endgame. I am tempted to write several different >>>evaluation >>>functions (one for pawn endgames, one for rook endgames, one for bishop vs >>>knight >>>endgames, one for endgames with unequal coloured bishops, and so on), but I am >>>afraid this would cause too big jumps when exchanges occur, make my static >>>exchange >>>evaluator too unreliable, and perhaps have other unfortunate side effects. Is >>>the idea >>>still worth a try? >>> >>>Tord > >Perhaps it is a good idea for your engine to "know" whether it is in the opening >[after book], middlegame, or endgame[before tablebase]. Better yet, it would be >nice if it could distinguish between different kinds of endgames. > >Of course, this implies that you would program the engine to utilize this >knowledge. > >Bob D. Recognizing the endgame phase is vital for any stronger engine. I'm quite sure Tord already makes that distinction and handles things like king-safety and moving the king to the centre accordingly. Richard.
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.