Author: Scott Gasch
Date: 13:38:39 10/21/99
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
This page took 0.01 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.