Author: scott farrell
Date: 05:50:00 11/09/03
Go up one level in this thread
On November 09, 2003 at 07:58:25, scott farrell wrote: moving my futility code to before makeMove made between 1%-8% difference in NPS. When in a non tactical position, it was about 2%, when very tactical, and lots of futility pruning it made about 7-8% NPS diff. I had to write a new method Board.doesMoveCheck(move). And as always, it complicated my code, the futility stuff is hard enough when doing it via lazy eval, and the chance there is a bug there now. Scott >On November 09, 2003 at 07:48:22, Daniel Shawul wrote: > >all I meant by alphaBeta is when you call ab(-beta,-alpha) and anything >associated with that, like a call to search hash etc. > >mmm.... if we are bad enough to futile-like-fail-low, and we switch sides, the >stand-pat will immediately fail-high - I take your point. > >You might still save 60%, but it depends on your maths, I count a futile pruned >node as a normal node, Ernst might not have counted the node, and it looks like >you save more nodes. Maybe he didnt have lazyEval either, so it would save more. > >I actually use my lazyEval in doing a futile move. My lazyEval includes >material, pieceSquare I include in makeMove incremently, pawn eval from pawn >hash, badTrade and a few other cheap things. Its whatever is quick, so it makes >my futility pruning a little more accurate without losing too much speed. > >Scott > >>On November 09, 2003 at 07:40:38, scott farrell wrote: >> >>>On November 09, 2003 at 04:55:40, Matthias Gemuh wrote: >>> >>>>On November 09, 2003 at 03:53:24, Daniel Shawul wrote: >>>> >>>>> >>>>> >>>>>>I do not remember if Ernst's paper said that you make the move first and then >>>>>>decide if it is futile. >>>>>> >>>>>>If it did, then it's definitely killing all the interest of futility pruning at >>>>>>depth 1! >>>>>> >>>>>>The idea is to prune before you make the move. So you stay at depth==1, look at >>>>>>the move, and say "hey, this move looks completely futile, let's ignore it!". >>>>>> >>>>>> >>>>>> >>>>>> Christophe >>>>> >>>>>A futile move is futile before you make or after you make it. >>>>> before >>>>> mat_bal + move_gain + margin < alpha => futile move >>>>> after >>>>> mat_bal + margin < alpha => futile move >>>>>Anyway my question is since you go directly to quiescent search >>>>>(where stand pat cutoff of all futile moves occur) after making the move, >>>>>we only saved ourselves "making of the futile moves".I can comprehend the >>>>>extended futlity pruning but not this.For me as long as standing pat cut off >>>>>is there , futility pruning at frontier is unnecessary,and if it is,it only >>>>>saves the time to make and unmake futile moves.Where does the 60% tree shrinkage >>>>>comes from?Please try to see where my proble is. >>>>> >>>>>Daniel >>>> >>>> >>>> >>>>Your logic seems sound for me. We seem to save only >>>>MakeMove() + UnmakeMove() + Evaluate(). >>> >>>I think you are wrong, you save: >>> >>>MakeMove() + UnmakeMove() +alphaBeta()+ qSearch()+ stand-pat+ Evaluate(). >> >>it is only make and unmake. qsearch never occurs 'cause we prefer to stand pat. >>And I don't understand what alphaBeta() means.Also if you use lazy eval >>the Evaluate() will not take time at all.So time wastage is >> Make + Unmake >>that's it. >>> >>>qsearch of course can be a few plies also. >>> >>>I think I do it after makeMove so its more accurate, I might try before makeMove >>>- and see what happens. But I am not sure if I can work out if its a checking >>>move too easily unless I makeMove(). >>> >>>Scott >>>> >>>>/Matthias.
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.