Author: Tord Romstad
Date: 02:30:34 01/22/04
Go up one level in this thread
On January 22, 2004 at 01:01:16, Uri Blass wrote: >On January 21, 2004 at 18:25:54, Tord Romstad wrote: > >>In general I am very sceptical about pruning schemes which prune moves >>before they are made. At that time, we simply don't know enough about >>the moves to be able to prune safely. > >I do not understand it. > >Suppose that the opponent has a big material advantage so you think the only >hope to get the score above alpha is by a capture or checkmate. > >Suppose that captures and checks did not return score above alpha. >Do you think that it is a bad idea to prune other moves before you make >them(espacially for program that are using fail hard like Crafty and not fail >soft)? I don't think it is necessarily a bad idea for *all* programs, but I know that it is definitely a bad idea for *some* of them. Futility pruning probably works very well for pure material plus piece square tables evaluations, but problems appear and keep growing more serious as you move towards the opposite end of the spectre. My conclusion when I experimented with futility pruning was that it worked rather well tactically, but that this was not enough to compensate for the loss in positional understanding. The problem with futility pruning is that it makes assumptions about how much a single move can possibly change the value of the static eval. Estimating the change in material is relatively easy, but guessing how much the positional evaluation will change is very difficult if you have many big positional terms in your eval. Ed tries to solve this problem by never pruning moves like passed pawn moves to the 6th and 7th rank, which helps to make the problem smaller, but in my experience it is not enough. There are often other moves which can dramatically increase the passed pawn eval (like supporting a passed pawn by a rook or blocking an enemy piece which protects the promotion square). When you add more and more terms to your evaluation function, it gets increasingly difficult to estimate the effect of a move without making it. You can try to add more and more exceptions to which moves you allow to be pruned, but this quickly gets very complicated, and there is a risk that the code needed to estimate an upper bound for how much a move can change the positional score will be so time-consuming that you could just as well make the move and call evaluate() before making the pruning decision. Sadly, but perhaps not unexpectedly, I have noticed similar problems with the lazy verification searches I have experimented with lately. Tord
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.