Author: Graham Laight
Date: 07:17:29 07/24/00
Go up one level in this thread
On July 22, 2000 at 22:21:19, Robert Hyatt wrote:
>This is not easy to answer. But here is a rough explanation.
>
>First, there are several knowledge 'modules' that are called when
>appropriate. IE before both sides have castled and developed all pieces,
>there is an EvaluateDevelopment() modules that is called. Once this has
>done its job, it is disabled for the rest of the game. There are similar
>modules for mating the opponent, evaluating passed pawns, evaluating
>passed pawn races, and so forth. And they are only called when it is
>appropriate.
>
>The rest is more complex. There are many 'major' terms... king safety,
>endgame outlook (ie passed pawns, outside passed pawns, pawn majorities,
>and so forth). These terms are phased in based on remaining material. IE
>king safety is multiplied by using three factors; 1 is the pawn structure
>around the king, 2 is the pieces of the opponent and how dangerous they
>appear to be (how close and how many are close) and 3 remaining material.
>As material is removed, king safety scores are scaled down.
>
>By the same token, as material is removed, endgame predictors are scaled
>up (ie an outside passed pawn becomes more valuable).
>
>This is all what I call "third order evaluation" since three complex factors
>are used to compute a number...
I've downloaded the *.c files for version 17.11, and I'd like to comment on what
I've seen.
Firstly, I have to say that the code is beautifully written, and very well
commented. Gold stars for coding and clarity!
Secondly, my comments probably apply equally well to other programs as to
Crafty. Unfortunately for Crafty lovers, this code is in the public domain. If
you are a Crafty lover, please don't feel that my remarks are aimed at Crafty -
I just want to use Crafty as a "typical program", so that I can compare and
contrast my ideas with the workings of a modern and successful chess program.
In order for me to compare my "model" program (which hasn't actually been
written, of course) with Crafty, let me briefly explain how I propose to do
evaluation: in brief, I want a database of evaluation functions, and, for each
position I want to evaluate, I want to pick from this database the evaluation
functions that are best suited to that position. Here's the process in a little
more detail:
* create a database (db) of evaluation functions (eval fns). For each eval fn
record in the db, also record some "indices" ("indices" is the plural of
"index") which will later be used to determine how well this eval fn matches the
position to be evaluated
* generate a chess position to evaluate
* calculate the indices for this chess position
* match these indices with the eval fn indices. For each eval fn, calculate a
"match score", and sort the eval fns into an ordered list (where the eval fns
with the best match score (ie most useful to the current position) will be at
the top of the list)
* select the eval fns from this list which best match the current position
* evaluate the position using these eval fns, and weighting the result of each
eval fn according to its match score
In contrast, Crafty's evaluate.c module puts all the knowledge within the code
itself.
I don't want to claim to be an expert on evaluate.c, because I've only looked
over it briefly, but I would offer the following observations:
1. The emphasis is always on speed. The author, again and again, is writing code
that will "return" and stop more chunks of code running if an initial test makes
it unnecessary
2. The knowledge is all in the code. For example, there's a chunk of code in
there which is designed to try to avoid the Stonewall Attack. I believe that if
somebody wanted to put a huge amount of knowledge in there, it wouldn't be easy.
They would probably resort to doing what is already done in there, and putting
in another chunk of code for each piece of knowledge they wanted to add. In
"Chess Skill In Man And Machine", they say that a human GM has 50,000 pieces of
knowledge (if I may paraphrase their talk of pattern recognition), so be
prepared to have a mighty, monolithic evaluation.c module!
3. The general philosophy of the program seems to me to be to go light on
knowledge: "travel light, slay 'em with speed" :)
4. For each piece of knowledge in evaluate.c, it seems to me that you're going
to have to do at least some sort of check to see whether it's needed or not
(though I admit that sometimes a check can dispense with more than one piece of
knowledge code in one go)
5. The test for the relevancy of a piece of code is binary - either you need it
or you don't. In my model, every eval fn is given a "match score" - and only the
eval fns with the highest match scores are run. If there is a lot of knowledge,
this could conceivably save time!
So - these are my initial thoughts. I believe that my model program has the
potential to evaluate positions better than Crafty can. I suspect that many
modern programs would, if the code was made available, be subject to the same
observations.
-g
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.