Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Checks in qsearch

Author: Vincent Diepeveen

Date: 14:38:37 06/22/00

Go up one level in this thread


On June 22, 2000 at 08:29:03, Robert Hyatt wrote:

>On June 22, 2000 at 07:55:53, Vincent Diepeveen wrote:
>
>>On June 21, 2000 at 11:12:23, Robert Hyatt wrote:
>>
>>>On June 21, 2000 at 11:03:42, David Rasmussen wrote:
>>>
>>>>I find that a lot of the games that my program loses, it loses because it
>>>>doesn't search checking moves in qsearch.
>>>>Anyway, how do people do that most effectively? I would like not to generate all
>>>>moves in the qsearch (just the captures), but then I will miss the noncapturing
>>>>checks.
>>>
>>>
>>>I did them in Cray Blitz, and in early versions of Crafty.  But I haven't
>>>done checks in the q-search since just prior to the Jakarta WMCCC event.
>>>
>>>You can control them to an extent...  ie when you get to the q-search, you
>>>can consider a check.  But if you look at a capture at the first ply or 2,
>>>then there is little point in doing checks deeper in the q-search because the
>>>'stand pat' will allow you to avoid the checks totally, earlier in the
>>>tree.
>>
>>76% of all checks give a cutoff in DIEP in qsearch
>>on average a check improves score with 2.9 pawns
>
>That is fine.  But if 76% of checks are giving cutoffs, you have a problem
>somewhere else, because _most_ cutoffs should be produced by captures, not by
>checks.

That's pretty hard to measure in a realtime program and i disagree here.
If you're in check, then you don't need to evaluate and have limited choice,
so the number of nodes you cycles you waste when being in check is
quite limited.

3 out of 4 checks giving a cutoff in a position which wasn't a cut node
without trying the check (otherwise beta pruning) is pretty good i think.

I'm sure most don't get such a good cut rate.

>
>
>
>>
>>But it's hard to figure out what checks to do and what you don't need
>>to do. It's simply hard work, but possible for everyone to do.
>>
>>It's hundreds of lines of code in DIEP.
>>
>
>That is hundreds of lines of code I don't have to deal with.  And since the
>entire concept of 'quiescence search' is flawed in a basic way, I want to make
>that part of my search smaller, _not_ larger.
>
>
>
>
>>>I personally don't do them because I don't like the q-search at all.  It is
>>>unreliable, and way too selective to trust.  You show me a position where the
>>>best q-search move is a check (say a capturing check) and I'll show you a
>>>position where the best response to a capture is _not_ another capture, but
>>>rather a quiet move that pins or indirectly attacks something.  The q-search
>>>misses way too much.  I think it is more profitable to make your basic search
>>>better by extending in the right places, since it already has no real inherent
>>>pruning errors other than a lack of depth.  I'd like to drive the q-search to
>>>almost nothing, as that would eliminate many errors.



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.