Author: Robert Hyatt
Date: 19:05:25 07/24/00
Go up one level in this thread
On July 24, 2000 at 10:17:29, Graham Laight wrote:
>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
This is called "lazy evaluation". Or "procrastinational evaluation". Never
do today, what you can do tomorrow. The point is that if you delay some eval
terms, you might get to exit without doing them at all..
It is all about speed... but it doesn't ignore accuracy at all...
>
>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!
without a doubt. But the alternative is really difficult too... if you have
N evaluation modules (your database approach). Then you get zapped because the
'selector' (database code) becomes the bottleneck... you might actually spend
more time trying to figure out what you are going to use for the eval, than a
large monolithic evaluation would spend...
I might agree with doing that if it makes the code more readable or more
maintainable of course... that is why most of the code in Crafty is written
as it is. It could go a lot faster, but then I would go a lot slower when
I make changes. :)
>
>3. The general philosophy of the program seems to me to be to go light on
>knowledge: "travel light, slay 'em with speed" :)
I wouldn't go that far. I don't do things that I consider to be computationally
prohibitive, but I have added a lot of things to the program over the past year,
particularly endgame-related... I try to avoid leaving things out because they
seem to be hard to implement efficiently... I often test an idea with a cheap
and dirty implementation, then if it does seem reasonable, I will spend more
time figuring out how to do it in an affordable manner...
>
>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!
This is only true in a broad sense. IE King safety isn't "on or off". It
is phased out as material goes away, or in as the king position gets shakey.
Ditto for endgame expectation scores...
Other terms interact. IE king safety, remaining material, location of opponent
pieces...
>
>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
I wouldn't begin to suggest that my approach is the cleanest. And the
evaluation is where the most work is needed. The search is doing fine on
good hardware... I think the main thing I have done, and will continue to
do, is shore up the knowledge. Fortunately I have some GMs that are willing
to point out things they see and don't like...
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.