Author: Uri Blass
Date: 03:13:08 08/30/04
Go up one level in this thread
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 think that you do not do what I consider as searching checks in the first ply of the qsearch. You do not search checking moves but extend only when the king is in check. I extend when the king is in check during the qsearch(not by calling regular search and my qsearch simply examines all moves) but I also search checking moves in my qsearch when the king is not in check. I do it in the first ply and in some cases even in the third ply but not later. It means that my qsearch may return mate even if it gets a position that is no mate position(mate is in the next move) and the mate is not done by a capture. For example after 1.f3 e5 2.g4 I get mate only by the qsearch inspite of the fact that Qh4# is not capture. Note that I do not call the regular search from qsearch when the king is in check because calling the regular search means that I may again search all checking moves in the qsearch because my qsearch may be again in the first ply and my search may explode(I do not want to search checking moves in every ply of the qsearch). Uri
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.