Joined: 07 Oct 2013
|Posted: Thu Oct 29, 2009 4:54 pm Post subject:
|What you are proposing to do is narrowing the width of the search,
which is dangerous unless your list of "good" moves is really really
good. Consider yourself warned.
To fit this strategy into the current framework, cache the result
of the static evaluation in the move object. Subclass "Search_Driver
public double Static_Evaluate_Move(commonMove mm)
with a check for your precomputed result. Your shortcut
version will need to include the equivalent of this:
double val = r.Static_Evaluate_Position(mm);
mm.local_evaluation = val;
mm.evaluation = val;
mm.gameover = r.Game_Over_P();
mm.depth_limited = r.Depth_Limit(current_depth+1,max_depth);
One final note about this optimization: I predict you will not be able to detect the benefit. You'll be skipping the second evaluation only for the moves that were actually used, and only for the non-terminal nodes. This is a very small percentage of the total nodes. This kind of thinking about the expected benefits of a proposed "optimization" can save you a lot of work and prevent accumulation of unnecessary complexity in your robots.