Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Qsearch Checks

Author: Stuart Cracraft

Date: 21:41:44 08/29/04

Go up one level in this thread


On August 29, 2004 at 22:49:58, Tor Lattimore wrote:

>On August 29, 2004 at 22:31:16, Stuart Cracraft wrote:
>
>>On August 29, 2004 at 22:08:13, Michael Henderson wrote:
>>
>>>On August 29, 2004 at 21:38:12, Tor Lattimore wrote:
>>>
>>>>I recently tried putting Checks in my QSearch, this brought me to the question,
>>>>should I stand-pat if i'm in check, but up lots of material? It does better in
>>>>some positions if I don't allow it to, but it blows up the search as well. Also,
>>>>is it better only to allow checks only at root of qsearch?
>>>>Cheers
>>>>Tor
>>>
>>>examining checking moves in the qsearch will slow you down a lot.  I find it's
>>>best to do check/singular response extensions in the main search.  The main
>>>search is smarter than the qsearch so you should probably spend your search time
>>>in that.
>>
>>My program runs at about 400k nps on a test suite without checks in
>>quiescence and about 3/4 of a ply deeper in the main search and about
>>8 ply less deeply in the quiescence search. Predictably, it does worse
>>(perhaps 5%) on standard test suites without checks in the quiescence.
>>
>>Personally, I think this is a good feature to leave enabled. The name of
>>the game is, after all, checkmate and I'd hate to be misevaluating
>>when the fireworks start.
>>
>>I call it "peace of mind".
>>
>>Stuart
>
>Do you search all checks in qsearch? or only at ply 0? Do you stand pat if your
>in check? or search all moves to get out of check?
>Cheers
>Tor

Answers are:

  search all checks in qsearch?            => yes
  only at ply 0                            => no
  stand pat?                               => no
  search all moves to get out of check     => yes

The implementation is simply upon entry to qsearch, check if in check.
If so, return the value of a main search done with depth = 1 instead
of doing the quiescence. The main search can extend but I have disabled
the various implemented extensions (pawn to 7th rank, recapture, one
reply only, verified null move (a kind of extension over a reduction),
etc. as none of these produced better results for very short searches
on a slow box.) They probably all help the program to play a better
game at slow time controls but that is not my targeted goal.

If falling through (no check), quiescence includes any capture (optionally
avoiding see-based losing captures or those that fail the delta pruning
(futility) based on the maximum positional score for the side-to-move.)
Promotions are optional and #ifdef'd as well.

Standard settings for program are: search all checks in quiescence
with the 1-ply main search. No see. No promotions. No delta pruning.
All of these are implemented and #ifdefed.

The reason for this is that I am optimizing for very short 1 second
searches on a slow box (1ghz P3) for eventual auto-tuning where
many self-play games will have to be played. Other standard options:
hash with replace if length >= depth, adaptive nullmove with depth > 6
being criterion for R=2 vs. R=3, examine all checks in quiescence
and all checks in main search,.

Another example: I don't use verified null move R=3 even though it
is a compile time option and chose instead to use a form of
adaptive null move as this has proven better for short searches.
I also don't use enhanced transposition cutoff, internal iterative
deepening and the like because all of these produced worse tactics
in brief searches.

In short, about the only things that improved tactics in short searches
were hashing, null move (adaptive better than regular), examine all
checks in quiescence and some in main search (depth <= 3).

I also investigated MTD(f) and left it commented out as the search is
rather unstable compared to PVS/NEGASCOUT which is more reliable.

Stuart





This page took 0.01 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.