Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: mate threat extension/null move

Author: Stuart Cracraft

Date: 15:41:58 10/05/04

Go up one level in this thread


On October 04, 2004 at 20:23:27, Don Beal wrote:

>Hmmm.  It's very helpful to post the actual code.
>My time is limited though.

No problem -- you've made good comments and de-lurked
and everyone enjoys that.

The bet was to decrease the WAC #141 problem down to <= 10
seconds without turning off the null move as one
claimant had done.

Although I am now at 49 seconds for WAC 141 solution with
null move enabled and not limited compared to the earlier 95
seconds, the <= 10 bet is still open. I'll hereby double the
bet to $100 to the first person who helps me achieve it directly.

>
>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.

Indeed, I am. SEE has been a permanent part of the program
since the main part of my SEE, not including the attack/defender
finder which feeds it, was given to me by a board member, and
improved my results.

My usesee variable was poorly named as it didn't span the presence
of the conditional on SEE very well and was used outside of it as
well. Bad and bug. I've moved it outside and renamed it "capture".
The idea is, is the move a capture? If so, search it first time
through only. Second time is for checking moves. That latter part
is not enabled as it causes my quiescence to blow up / slow down
and impacts my WAC results severely.

>(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.

Poor documentation in this case and noted prior to your
post. Thanks for the confirm.

>(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.

No matter what I do, my qdepth == 0 of genmv() for captures
and check-giving blows me up. I've doublechecked it quite
a few times to ensure it wasn't all moves being investigated
at qdepth == 0. Not sure why it blows me up. But it does.

>(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,

I have to do incheck tests to ensure moves are legal.

>(repetition is only possible at root, and down a check-evade
>sequence), doing string handling in qsearch.

Well, I do want to detect draws in the tree. Draws are possible
by agreement and do not require check sequences.

>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.
>

It is not bad but with bitboard attack implementation with
incremental updating between moves, I think the program
would do better.

>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:

I do like the three-tier qsearch you posted. I've printed it
out and keep it in a cupboard with all my printed computer chess
materials including most of the ICCA.

>
>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.

See later post for followup.




This page took 0.04 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.