Author: Will Singleton
Date: 22:37:08 12/07/98
Go up one level in this thread
On December 07, 1998 at 23:19:25, Robert Hyatt wrote: >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. Ok, that's what I figured. So I guess I have to try to do all that stuff in the eval, and hope for the best. But I wonder about the "tempo" problem. I give a penalty if the ply 1 move is reversed at ply 3, to discourage easily refutable ply 1 moves. But perhaps that's just a problem when the search is shallow, as a deeper search should find a better ply 1 move. > >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... > > I had actually thought of that, and shuddered. > >>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... > > True. Good point, bad example. The point would be valid for "queen-move before developed." >> >>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... I get in more trouble due to castling late. Finally I just put in a huge bonus for castling when able. But you're right, if you can search deep and well enough, you should be able to castle at the right time. Theoretically... Thanks for your comments. Will
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.