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: [snip] > > >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 >it. > > > > 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 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.