Author: Robert Hyatt
Date: 10:09:30 01/20/06
Go up one level in this thread
On January 20, 2006 at 08:53:48, Michael Neish wrote: > >Hi, I just tried a little experiment with my as yet simple program. I added a >mobility function for the Queen as the only way of scoring this piece, i.e., no >piece-square tables. > >When I ran the program, I found that it increased the required number of nodes >to reach the same depth in a given position, by roughly 50% to ply 11, which I >found curious. > >Thinking about it, adding this new feature could be resulting in a greater >number of positions that score roughly equally, hence search needs to sift >through more nodes to find the best one. The opposite is true: when there's a >really obvious best move like moving one's Queen away from a Pawn that's >attacking it, search tends to go deeper faster since it can quickly eliminate >bad branches. "equal" scores are good. Because remember pruning is for V <= alpha or V >= beta. More likely the mobility is just introducing more "noise" into the scores. That's why material-only is usually so good, most moves don't drop pieces or pawns, and as a result the score is always the same, resulting in good pruning. The more "variability" you introduce into your scoring, the larger the trees grow because it becomes harder and harder to differentiate between two branches... > >Have I got the correct interpretation? > >If so, would adding more refinements to Eval() result in an even greater number >of nodes required to the same depth, or not necessarily? It depends. It will affect different positions differently. > If it would, what can >one do to prevent it? Could one, say, design Eval() so that position scores >don't cluster around the zero mark, but are instead more spread out so that >search doesn't get bogged down trying to distinguish between positions that are >just a point different? Easier said than done, maybe. That's actually the worst thing you can do for tree size. And for playing skill, since you want your eval to recognize minute differences when choosing between moves... > >Properly done, though, I wonder if it might be a viable strategy for reducing >the size of the tree. > >Any comments? > >Cheers, > >Mike.
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.