Computer Chess Club Archives




Subject: Re: What is Botvinnik's legacy to computer chess?

Author: KarinsDad

Date: 11:47:24 02/22/00

Go up one level in this thread

On February 21, 2000 at 21:18:37, Christophe Theron wrote:

>Many programs do that already.
>From my own experience, most rules used by human players do not help a chess
>program to play better.
>I don't mean that no rules coming from human experience will help, I mean that
>most of them don't help.
>So the job of the programmer is to carefully select which rules to use. In the
>process, you can have to discard rules that is considered as very important by
>human players.
>Just an example: the concept of "tempo" is absolutely useless for a chess
>program. Just my opinion of course. I don't see what to do with this concept,
>and I don't think my program is lacking it.
>If someone uses this concept in his chess program, I'm interested to hear about
>    Christophe

Hmmmm. An interesting concept.

My program has a post-processor that comes up with a series of good and bad
"ideas" (i.e. human rules as you specify above) based on the original position,
how far into the game it is, etc.

An example of a normally good idea is to get a rook to the 7th rank. An example
of a normally bad idea is to push pawns in front of a castled king before the
endgame (whatever that means).

My program keeps track of multiple PVs at ply 1 (best move PV, second best move
PV, etc.). If the best x moves have a +- 0.2 pawn score, then it picks the move
whose PV leads down y ply to a position with the most number of good ideas and
the least number of bad ideas (i.e. it attempts to play positionally based on
similar tactical scores, but different positional elements).

The idea is that most positions have about 3 to 5 relatively equal moves that
can be made. Most likely, any program that you play against will play one of
these 3 to 5 moves. However, a miniscule differential on score should not be the
only determining factor as to which of these moves to pick. Positional elements
for positions that you may be likely to arrive at in the actual game should be
considered as well (in an attempt to emulate the human decision making process
of weighing pros and cons of potential future positions).

If I wanted to add tempo to the series of post-processor ideas, how would I go
about it? Hmmmm. I could attempt to use development. If I have 5 pieces and 3
pawns developed down one of the PVs and my opponent had 4 pieces and 4 pawns
developed, I could be said to have a partial tempo (and a full tempo if 2x ply
into the entire game, I had one more piece or pawn developed then my opponent,
of course, it would have to take into account things such as castling, etc.).

Now, some people may argue that tempo and development are not the same, but as
you stated, most of this comes out of the normal search tree anyway. In my case,
I would be looking for that extra little umph.

You could put this type of thing into the evaluation function, however, I do not
see it as important enough a rule to do on every position (let alone that
captures could screw it up).

KarinsDad :)

This page took 0.01 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.