Author: José Carlos
Date: 00:56:14 12/31/03
Go up one level in this thread
On December 29, 2003 at 20:16:35, Mridul Muralidharan wrote: >On December 29, 2003 at 20:07:23, Mridul Muralidharan wrote: > >>On December 29, 2003 at 18:16:39, Tord Romstad wrote: >> >>>On December 29, 2003 at 16:01:08, Andrew Williams wrote: >>>>I make sure that I have a legal move available before pruning stuff. >>> >>>This is good advice, and reminds me of an amusing bug I had in early versions of >>>Gothmog >>>(while I was still using normal futility pruning): In positions which were so >>>bad that all >>>moves were pruned because they had no chance of bringing the score anywhere >>>close, >>>to alpha, the engine thought: "I have no moves, but I'm not in check -- It's >>>stalemate. >>>Let's return 0". As a result, the engine would sometimes make horrible >>>blunders, and >>>print out PVs where it sacrificed almost all its pieces, with a draw score at >>>the end of >>>the line. >>> >>>Tord >> >>Ah ha ! >>One of the first ches playing versions of emss had the very same bug :) >>So I have company ;) >> >>Mridul > >And to answer the question on pruning. >I would strongly advice against very basic forms of pruning in general and >futility in particular since this seems to be the most famous. For the "famous" formulation of futility pruning to work you must have a simple qsearch that can stand pat if material is clearly above beta without even calling eval, or at least implement some kinds of lazy eval. Futility pruning then makes the last ply kind of a bridge between regular search and qsearch, behaving sometimes like regular search (in good positions compared to alpha) and like a qsearch (in very bad positions compared to alpha, because you only try a very few captures there to desperately try to bring score above alpha). For complex qsearch, where you do something more sophisticated, like generating checks, not allowing standing pat if in check or if king safety score is bad, etc. the futility concept just doesn't work. You could, however, adapt the idea to make it fit in your schema. Think about how to save some useless work in very bad positions in your last ply. In those bad positions, try to behave like if you where already in qsearch and use the same pruning as there. Just an idea... José C. >I did a bit of research on pruning , including lot of null move related tricks , >king safety related tricks , etc , etc. >In the end threw all of them out and decided against pruning. >Mess is a very very slow searcher - so loss of nps while eciding this was not >the deciding factor as is usually in the case with others. (definitely this did >worsen situation a bit). >In mess I have a very heavy qsearch , and moderately heavy eval (with diap , >hiarcs around - cant call my eval big :) ) >This along with pruning was disasterous for mess : even very very conservative >forms. >Well not all methods were flawed , but there were too many "if & if & if" >conditions and crazy patterns (which sadly did appear in complex middle games) >where they used to fail - so in end decided to remove them. > >Note - these were related only to mess - maybe for others it will vary. > >Regards >Mridul > >PS : Geoff , instead of directly calling > >" >takeBack(); >/* try next moved at this depth */ >continue; >" > >I think the usual convention with (Extended) futility pruning/Razoring is to >call QSearch here ....
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.