Author: Don Beal
Date: 17:23:27 10/04/04
Go up one level in this thread
Hmmm. It's very helpful to post the actual code.
My time is limited though.
My advice remains that the best next step would be to
get a reliable cost-effective qsearch going, so I'll
offer a few comments on your code for that, in case
that helps you.
(1)
a bug: if you don't define SEE, you have the "usesee"
local variable uninitialised which will cause bad things.
However, I assume you are testing with SEE defined at present.
(2)
another possible bug, or may be just duplication and
waste of execution time: You have a comment "// First time only"
after the line "ifdef SEE". But I see nothing in the the code
to prevent the execution stream going though this
point on the second pass.
(3)
if you define QCXX (checks at ply 1 of qsearch), you
call genmv which I assume generates all moves. Then
the pass-1 moveloop appears to call quiesce on them
all (except any which are illegal because the leave
the moving side's king in check):
if (!incheckopp(bd))
if ((timethru == 1 && usesee)
...
value = -quiesce(bd,ply+1,-beta,-alpha,mvs,2,qdepth+1);
So this is essentially looking at all moves, not just
checks. It's more like another ply of full width search
than a capture list augmented by checks, and hence is doing
more work than is recommended for the qsearch.
(4)
In general, the overall implementation seems to be too slow for
good performance. I agree with robust and easy-to-understand
code (assuming these are achieved!) at the expense of some speed,
but I think that, considered as an implementation of the kind
of qsearch I recommended in my last post, and considering that
your eval is currently only pcsq, you are running several times
slower than an efficient implemention.
Some things that will slow you down: testing for incheck
everywhere in qsearch, testing for repetitions everywhere,
(repetition is only possible at root, and down a check-evade
sequence), doing string handling in qsearch.
You might be limited by your SEE, but with a fast SEE in place,
I think a fast implementation could run several times faster
than your current one.
I think inproving the qsearch cost-effectiveness is beneficial
whatever you use your program for. If that isn't helpful,
here is a final suggestion:
Although I haven't had time to study your main search, there is
another lever you can add to your control panel. Replace:
// test for null move prune
value = -search(bd,sdepth-1-reduction,ply,-beta,-beta+1,
mvstr,SAVETOP,verify,REDUCENOTOK,checked);
by this:
// test for null move prune
value = -search(bd,sdepth-1-reduction,ply,-beta,-beta+1,
mvstr,SAVETOP,verify,REDUCENOTOK,checked) + WACBOOST;
where WACBOOST is a bias that increases tactical prunes.
Hold the search time constant, so that more prunes allow
deeper search, and try values between zero and a half-pawn,
for example a quarter-pawn, to see if that improves WAC score.
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.