Author: Christophe Theron
Date: 15:26:56 06/19/98
Go up one level in this thread
On June 19, 1998 at 01:32:38, Roberto Waldteufel wrote:
>
>Hi Don,
>
>Thanks for your detailed description of Cilkchess' MTD(f) implementation. Maybe
>I'll try it again at some point, but it sounds quite tricky to get right. I
>don't use a lazy evaluation (never have done), but then my normal evaluation is
>not very sophisticated. It only takes into account material, bishop pair,
>open/semi-open files near kings and attack counts on squares adjacent to kings.
>However, I also use a preprocessor which sets square values for all the chessmen
>based on those features of the position that are unlikely to change during the
>search, such as squares on which pawns would be passed, open/semiopen files for
>rooks, squares for rooks behind passed pawns, centrality etc.
May I give my point of view about this?
Among the points your mention above, all should be computed dynamically (except
centrality), and not preprocessed. A program evaluating these things in each
leaf is likely to beat your program very often, unless you are able to compute
at least one ply deeper or more.
For example a passed pawn is a very important dynamic feature. Too important to
be only guessed at the root.
And in a closed position, your program is going to have trouble to find out how
to open it in the right way and put his rooks in the right place.
Just my opinion, of course...
Christophe
>I have tried other
>things, but came to the conclusion that it is best not to attempt preprocessing
>features that may change frequently, since then the information is too often
>inaccurate at the leaf nodes. I seem to have achieved a fairly good balance
>between the things I evaluate in the evaluation function and those I preprocess,
>but there are many things I still need to consider, perhaps pawn structure is
>the most important omission at present. I would be very interested to know what
>were the features that Larry recommended for your preprocessor, and whether any
>of these things were later moved to the terminal evaluation to improve accuracy,
>albeit at the cost of some speed.
>
>Over the past couple of days I have ported my program from an old 16-bit DOS
>compiler to a much superior 32-bit compiler (alas, no alpha 64-bit technology
>yet, but Pentium 333MHz is not too slow), and in the process of optimizing my
>code for this new platform I have been re-examining the issue of divideing the
>evaluation effort between the preprocessor and the evaluation function with a
>view to expanding the positional features it considers.
>
>Best Wishes
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.