Author: Robert Hyatt
Date: 20:19:25 12/07/98
Go up one level in this thread
On December 07, 1998 at 18:30:08, Will Singleton wrote: > >I have an issue I've been thinking about for awhile, appreciate any >comment. > >In order to play reasonable moves, I have special scoring functions that >apply only to the ply 1 move. They include a queen-move when not >developed penalty, castling bonus, kside pawn move penalty, >development bonus, king move after castle penalty, and a couple more. >These scores are set at the time of the ply 1 move, and added to the >evaluation score for all ensuing ply. > >Now I have a theory about this, which is that this is a bad thing. I think it >can lead to inconsistencies in scoring, and also result in a bigger search >tree. For example, the hash table will contain a certain score for a >position, which will differ from that same position reached thru >transposing the moves at ply 1 and 3. While the stored hash move may >be good, the score is not good as a valid or as a limit score. > This is basically a bad idea. You don't want to put *any* "path-based information" into your evaluation, because hashing doesn't take the path into consideration, and you get inconsistent things. There is a way to do this that makes your code look very ugly... keeping two pieces for the score, one path-dependent and one that is not. You add them together to use them, but when storing something in the hash you back out the path-dependent part. Not my cup of tea... >Another example: let's say I want to inhibit White from moving his >castled kside pawn at g2. The ply 1 score penalty will handle this, but >ply 3 might like g4. That will cause the ply1 move to be suspect, >because it relies on a bogus ply 3 move. you are using path information here to evaluate something that has nothing to do with the path. IE playing g3/g4 is always bad. whether at the root of the tree are at the tips... > >So I have convinced myself that this ply 1 scoring method is wrong, and >I want to replace it. The possibilities are 1) use a piece-square table to >inhibit/promote moves, and 2) keep ply 1 out of the search. Method 1 >would seem to suffer from the familiar problem of getting the program to >understand that it must play a certain move (like castling) *now*, and >not put it off until ply 3. Method 2 would involve scoring each ply 1 >move, then doing the search starting from ply 2, and adding the ply 1 >score to the score returned from the search. That would seem to avoid >the hash-table problem, because the ply 1 scores would never be >stored. But I don't know, seems like there are still problems with this. > >Comments? > >Will You simply have to tune this... IE in the game of chess, there is nothing that says to castle *now* rather than later. A famous GM once said "castle if you want, or if you must, but *not* just because you can." The moral is clear... no need to castle too early and give away where your king is going to live before your opponent has committed pieces to specific squares. And if you do a reasonable job of searching and evaluating, castling at ply=9 is just as good (and maybe better) than castling at ply=1... Do it "just in the nick of time" for best results...
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.