Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Futility Cutoff futile?

Author: Koundinya Veluri

Date: 13:03:41 09/01/01

Go up one level in this thread


Just to bug you... :)

>You could give it another try :)
>
>forgive me to insist replying :)
>
>
>int ev=eval();
>
>if (ev>=beta+window)
>{ return beta; }
>
>then see captures with the normal alphabeta window
>
>then:
>if (ev+window<alpha)
>{ return alpha; }
>
>then see noncaptures if you are still here.
>
>-----------
>the main diff. is not see captures aditionally with bigger window.
>-----------

This makes a lot more sense. I guess you're trying to simulate a qsearch in the
ply before qsearch.

My basic idea was that qsearch returns an estimated score for this position. If
this position is quiet (no extensions triggered) and the estimated score is
already far from the window, it is not likely that the proper score (i.e., the
score after proper searching) will be inside the window, so I assume it is safe
to skip that position and return a bound.

The beta pruning in both versions is exactly the same so ignore that for a sec,
and your version is still _far_ different from what I'm doing, in my opinion.
Here are the conditions for pruning with alpha:

In my version:
When all the captures fail low, i.e., return score <= alpha-window, return. This
means that no captures caused a significant fluctuation in score (i.e., quiet
position).

In your version:
When any one of the captures is really good and returns a score far greater than
alpha but less than beta, we will probably prune this position. To me, this
seems dangerous since you're skipping a position with strong captures. To stress
what I mean, here's your code:

>then see captures with the normal alphabeta window
>
>then:
>if (ev+window<alpha)
>{ return alpha; }

To get pruning here, alpha has to increase a lot, such that it is greater than
ev+window. But if alpha increases that much, it means this position has a strong
capture (hence is not quiet) and pruning it could (perhaps rarely) be dangerous,
or perhaps the window has to be large (which restricts pruning).

So the conditions for pruning are _very_ different, almost opposite! It seems to
me that in your version, chances of getting pruning is lower in positions where
all the captures fail low (because alpha doesn't change). I hope I didn't make
any mistake.

You are right though about my method. I do search captures with a larger window,
but I am forced to, since I use the returned qsearch value to decide pruning.
I'm sure both methods will work properly provided enough testing is done, but it
looks like both have their drawbacks: mine with the risk of larger trees, yours
with the risk of dangerous pruning.

Please feel free to correct me :)

Koundinya

>
>In your code:
>
>suposse quiesce>=beta+window
>then we are going to cut off usually quicker here in the code above because the
>captures are seen with a smaller window.
>
>or suposse quiesce<=alpha-window
>this is similar as to ask if ev+window<alpha after captures, sometimes equal and
>sometimes not...
>I realize now it is NOT exactly the same..., so I were a bit wrong in this point
>am sorry, but this ev+window<alpha is a little more what one would want to ask,
>and prunes even more. With less nodes.
>
>
>Ok, good bye now.



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.