Author: Ricardo Gibert
Date: 19:38:34 10/21/99
Go up one level in this thread
On October 21, 1999 at 16:38:39, Scott Gasch wrote: >Hello, > >I've been analizing games my engine lost and noticed a common problem -- it gets >a piece stuck with terrible mobility and subsequently can't defend itself (or >attack the enemy). > >So I have been trying to come up with a cheap way to factor piece mobility into >the eval. I thought of this: put counters in the move generation routine that >reflect the number of valid moves for piece X... each time I call GenerateMoves >these all get reset to zero and then incremented every time, for instance, a >bishop has a valid move... etc. > >So then QSearch will make one of the moves returned by NextMove (affecting one >piece's mobility) and then, maybe, call Eval. Eval can then use the counters to >give bonuses for piece mobility pretty accurately (one piece -- the last one >moved -- may have increased or decreased mobility but most are accurate). > >My question is this: from your experience is this approach cheaper than adding >mobility code to Eval? There are a lot of times the moves are generated that we >do not care about this data (any ply where we still have depth). But it seems >like a waste of instructions to do a conditional just to save one increment... >and it seems like a waste of code to duplicate the move generation routines >(version 1 has increment counter code and version 2 does not). I am really >worried about slowing the engine down too much with this code. I am already >down to about 80k NPS (mainly because of the size of a move, I've decided, but >that's another story). I am afraid that if I improve Eval but slow it down too >much I will start not getting very deep... and performing worse for my change. > >Thanks, >Scott Mobility has quite a bit of overlap with the concepts of centralization, space & pawn structure. Something you need to take into account. You don't want to spend a lot of time evaluating something already covered by other parts of your eval. Be careful you don't elicit odd behaviour like your pieces appearing to be phobic of each other e.g. (1) King or other rook moving away from a rook to give it an extra back rank square(s) to move to; (2) Knight decentralizing to give more scope to a bishop. Your forces tend work together better if they are not too far apart. This is actually a noticeable characteristic that can differentiate between human and computer play. What matters more is how many "relevant" squares a piece bears on.
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.