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.