Author: Dan Homan
Date: 17:14:55 12/17/97
Go up one level in this thread
Hi Don,
I do is just what was suggested by Bob and Bruce. I always
use R = 2 and call the next level of search from my null move code
in the following way....
if (depth > R)
best = -pvs(-beta, -alpha, depth-1-R);
else best = -qsearch(ply+1, -beta, -alpha);
If I understand you right, you do something like...
if(depth > R)
best = -pvs(-beta, -alpha, depth-1-R);
else best = static_eval_function();
Where static_eval_function() does something like what you
described in your post. I don't see why this would be slower,
although the static_eval_function() might be less accurate than
carrying out the qsearch.
On move ordering....
Bob's point about using killers after captures because they are faster
than generating the rest of the moves (for use with the history
heuristic)
is an interesting one. That must be bit-board thing, because I don't
see a good way of doing that in my current framework... I can see
how it would be quite a bit faster if I didn't have to generate all the
moves at each ply.
I see your point about testing on more than a few positions. So far
I've been using the WAC positions. I usually test the first 20
whenever I make even a minor change. (For some reason I still
can't get #2, much to my frustration.) If I make a larger change,
I will usually look at the first 50. I think you are right that looking
at the positions individually rather than some average is important,
but it is harder if I try to do the full set of 300.
- Dan
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.