Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Cutting down my qsearch

Author: Dieter Buerssner

Date: 07:58:27 04/23/01

Go up one level in this thread


On April 23, 2001 at 10:11:00, Ulrich Tuerke wrote:

>On April 23, 2001 at 09:48:40, Dann Corbit wrote:
[...]
>>
>>Just like NULL MOVE or any selective element for searching, it will cause some
>>problems to be solved more slowly.  However, I suspect it will cause *most*
>>problems to be solved faster.  That is the way it works with every good idea.
>
>Completely agreed. The above mentioned risk arises essentially if you have
>chosen your cut threshold (too) close to alpha.

There can also be some other "risks", depending on what the qsearch does.
E.g. When you don't allow stand-pats, where the side to move is in check.
When you cut such nodes, depending on material gain and alpha, you can miss such
situations.

I try to be careful to do the pruning in qsearch in certain situations. When you
capture the last pawn of the opponent, you can reach a draw score. An example
(similar to what we discussed recently). KNNP vs. K will have an high material
advantage. If you grap the P, the material gain is much less than the gain in
score. Also, when reaching pawn endgames, I try to be careful.

I think, this pruning idea saves less, than one could think. When you prune the
node, all work, that would be needed for this node is a call to qsearch, and a
call to eval (which will fail high).

For the threshold, I use something based on largest positional advantage
(dependant on the side). Of course, this won't give many cutoffs with Vincent's
20 pawns :-)

Regards,
Dieter




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.