Author: Antonio Dieguez
Date: 14:09:36 09/01/01
Go up one level in this thread
On September 01, 2001 at 16:03:41, Koundinya Veluri wrote:
>Just to bug you... :)
:)
...
>This makes a lot more sense. I guess you're trying to simulate a qsearch in the
>ply before qsearch.
sure.
>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.
ok...
>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.
probably? only if the difference is more than .072 for me, wich is a margin only
surpassed in very few moves (without counting sometimes extensions at the next
ply)
>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.
just that alpha doesn't necessary have to improve a lot, the position can be bad
too :)
>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
I respect what you said, but still there is an improvement for you that does not
conflict with what you say about the position being inquiet.
For example:
(the improvement of this depends in your prunning at your qsearch though)
int ev=evaluate(...)
if (ev>=beta+window)
{ return beta; }
then see captures with this window: (alpha-window,beta)
if that alpha-window was not improved then return alpha.
(less nodes, and now exactly the same, if I am not mistaken...)
toño.
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.