Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Qsearch Checks

Author: Anthony Cozzie

Date: 18:49:26 08/30/04

Go up one level in this thread


On August 30, 2004 at 15:30:07, Stuart Cracraft wrote:

>On August 30, 2004 at 08:17:35, Anthony Cozzie wrote:
>
>>On August 30, 2004 at 00:41:44, Stuart Cracraft wrote:
>>
>>>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
>>
>>I have investigated autotuning pretty thoroughly, and I don't think any method
>>that involves playing games will work.  The problem is that you have to play _so
>>many_ games that it takes forever.  I posted my autotuning algorithm (actually a
>>bit of a tweak on what the deep blue guys did) a while back.  You can probably
>>find it in the search engine; it works really well.  The only thing it doesn't
>>do well is PSTs, because it tends to overfit (you need a _lot_ of games to get
>>PSTs right).
>>
>>anthony
>
>I'd be interested in seeing the code. Can you send a pointer to it?
>
>Stuart

Or, you could write your own code according to the reasonably detailed
description I gave . . . ;)

anthony



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.