Author: Uri Blass
Date: 23:11:07 10/02/05
Go up one level in this thread
On October 02, 2005 at 22:06:11, Scott Gasch wrote:
>On October 01, 2005 at 08:13:00, Michael Diosi wrote:
>
>> 8/8/pppppppK/NBBR1NRp/nbbrqnrP/PPPPPPPk/8/6Q1 w - - 0 1
>
>Monsoon takes hours to see this because it plays the captures first and then
>gets stuck in the qsearch swapping off all the other trades. This is a really
>interesting position and I wonder how other engines are solving it so quickly.
>Naturally if you search checks before captures you will solve this but you won't
>have as efficient a search tree. Is there some logic for "that's a really
>dangerous check!" other people have used? Or is it more like "at depth=1 we are
>30 ply deep in qsearch, stop already!"
>
>Scott
There is no reason to stop only at depth=1 because if this position happen not
at depth=1 you still may have a big qsearch.
I think that the best solution is to limit the number of captures that are
allowed in a given ply and to give the qsearch depth as parameter.
You can have some array that tells you the number of moves that are allowed in a
given ply of the qsearch and decide to return alpha if they were already
searched.
It may be logical to search 10 different captures in the first ply of the
qsearch but I see no reason to agree to search 10 different captures when you
are 7 plies after the initial position in the qsearch and it is more logical to
return alpha if the first capture that was searched failed low.
I do not have an array of number of allowed captures in Movei and I simply stop
the search after 7 plies but I think that something like
captures_allowed[32]={15,10,7,4,3,2,1,1,1,1,1,1,...} seems more logical
when the number of capture lines in the qsearch is limited by 15*10*7*4*3*2
Uri
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.