Author: Ratko V Tomic
Date: 07:42:35 10/27/99
Go up one level in this thread
> When I spoke of a "good evaluation function", I did not mean a highly > accurate one. I meant one that isn't random, isn't constant, has a > reasonable, if minimal, understanding of what is going on, i.e. it > doesn't think that getting oneself checkmated is a good thing. I'm > not asking for a "highly-tuned specimen" here. The problem with minimaxing (via alpha-beta, or in any other way) of inexact values is that due to the error propagation up the tree, the evaluation error increases with depth. Of course, in chess (checkers and similar strategy games), there are other beneficial effects of minimaxing unrelated to the positional evaluation (such as detection of material loss, traps which cause early termination), which for most root moves offset the drawbacks of the larger positional error. Additional serious problem with adding a large number of positional terms in evaluation function (the "lump sum" dogma of the conventional chess programming) is, as suggested earlier, that the error also increases with the number of such terms. Used in such manner the multitudes of terms cause the program to follow (through the larger part of the game) the ficticious "gains" which are artifacts of the noise band of the "lump sum" positional evaluation, i.e. among the several candidate root moves close in the backed up "value" to each other, the program's choice is essentially a coin-toss. > All of that multi-level stuff can be done in one function. One. In principle, yes. In the similar way, you don't need even that single function -- a single lookup in the appropriate table base will give you the best move. Again, in principle. In practice (with limited computing resources) it isn't so in either case. The "multi-level stuff" is a way to express how are chess knowledge and the search most effectively applied, in a way most suitable to the strengths and the limits of each. Stuffing the positional knowledge into the "lump sum" at the terminal nodes of the alpha-beta tree, as the current dogma prescribes, is quite different than using the knowledge to guide and constrain the search. If you have ever analyzed positions in depth, with the help of a chess program, you are aware that letting program think on its own for a day isn't nearly as effective as playing out the lines you identify as important, and letting programs "think" few minutes per proposed move, even though you may have a highly negative score against that program. A much weaker human player (other than a novice) + program used in this manner will be stronger than the same program alone, in the longer time limits (i.e. in the limit of the maximum strength of each opponent). This is true, even though the program may have explicitly more positional chess knowledge packed in its evaluation function than a human player aiding the program. The reason for increased strength of the combined player is in the manner the little chess knowledge the human may have is used in a more effective way and in a way more in tune with the nature and purpose of the positional chess knowledge (i.e. it was designed for human-like search, which goes with a great deal of reasoning and common sense, especially with checking out specific kinds of followups for specific types of advice, and not to be converted to points and all added together at some "quiescent" node). > You can denigrate a "lump sum" evaluation function all you want, > but in the end you have to make a choice between various positions. I didn't "denigrate" but merely presented an argument from several angles why the "lump sum" isn't a very good method (the only advantage it has is the ease of programming compared to other ways). You didn't exactly address any of the specific points presented. > When you do this, you are "lump summing", whether your > evaluation architecture has five levels of indirection or > none. Whatever evaluator you have is selecting a preference > between a countably infinite number (or less) of possibilities, > which means the evaluation function is representable as a > mapping from a position to an integer. The same goes for direct full chess-tree table-base lookup. In principle yes, but without practical relevance. The actual positional evaluation terms as used in the chess programs are based on human chess theory. So these concepts (and the corresponding derived formulas/algorithms used in the programs) are optimized for use in particular manner -- for human-like search guidance / constraints, reasoning and followups.
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.