Author: Stuart Cracraft
Date: 12:30:07 08/30/04
Go up one level in this thread
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
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.