Author: David Eppstein
Date: 14:30:25 08/01/99
Go up one level in this thread
On July 31, 1999 at 14:34:11, Albert Silver wrote: >On July 31, 1999 at 13:35:11, David Eppstein wrote: >>Of course. In the game I programmed, Fanorona, fortresses are an extremely >>important feature of the endgame. Often, to win, you need to sacrifice some >>material to break a fortress, and yet still retain enough of a material >>advantage to clean up afterwards. My evaluation function has code to recognize >>many commonly-occurring fortresses, and give them a bonus slightly greater than >>the amount of material needed to be sacrificed to break them, so that the >>attacking side is forced to actually make the sacrifice rather than just >>sitting around on a winning position. >> >>If fortresses occurred more frequently in chess endgames, I bet you'd see >>similar code added to chess program evaluations. Of course, the other way of >>handling a lot of these situations is with endgame tablebases... > >Yes, but what about the fortresses that cannot be won? Can the program create >them, an extremely valuable tool albeit uncommon, or recognize the possibility >in order to prevent their creation by the opponent? This would be a good basis >for a couple of test positions IMO. As long as the evaluation function correctly evaluates fortress positions, and as long as the tactics are within the search depth, all of the following types of play will happen automatically when appropriate: - Creating a fortress to escape to a drawing position - Sacrificing material to create a fortress - Preventing the opponent from reaching a fortress - Sacrificing material to prevent a fortress from being reached - Sacrificing material to break up a fortress. In fact I have seen my program do all of those things. The times when my program plays badly in the endgame are more often when an unusual fortress exists that it doesn't recognize, in which case it will play aimlessly instead of making a correct sacrifice, play into a line that it thinks is winning but merely draws, not defend precisely enough, etc. This is not magic, and it does not require "intelligent" planning or nonstandard search algorithms, much as I would like to find interesting algorithms. You just need to have an evaluation such that the value of the positions at the ends of these lines looks better than the value of the positions after less appropriate lines of play. If current chess programs do not include code for correctly evaluating fortresses, I doubt it's because such code is impossible to write, but rather that fortresses occur too infrequently to be worth the slowdown in evaluation time for other positions.
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.