Author: Tim Foden
Date: 10:03:38 09/20/01
Go up one level in this thread
On September 20, 2001 at 07:21:57, Dieter Buerssner wrote:
>On September 19, 2001 at 10:58:11, Tim Foden wrote:
>
>>On September 19, 2001 at 10:32:25, Dieter Buerssner wrote:
>>
>>>From you posts, I have seen, that GLC is really good at solving mates (I mean
>>>especially the Leonid positions, where Yace is often chanceless.) Do you have
>>>any special trick, that you want to share? :-)
>
>Thanks for your answer.
>
>>I guess it is a combination of these things:
>>
>>1. Search extensions. I don't restrict them in special way. They are just
>>restricted to a maximum of 1 ply in each node.
>
>I am doing this a bit different. I restrict some extensions, when already too
>deep in the line. On the other side, in rare cases, I allow more than one ply.
>
>>2. Qsearch depth is restricted. Otherwise some of Leonid's positions simply
>>explode.
>>
>> if( -depth >= max(4 * PLY, m_currentDepth * PLY) )
>> {
>>#ifdef DEBUG_SEARCH
>> WriteDebug( ply, _T("q %d / qdepth %d\n"), ply, currentEval );
>>#endif // DEBUG_SEARCH
>> return currentEval;
>> }
>
>I am not doing this. Perhaps, this can help very much in Leonid type positions.
>Did you just guess, where to make the cut here, or did you do some tests?
I did some ad-hoc tests. I just fiddled with it until it seemed to make no
difference to normal positions. However, it helps a lot on some of Leonids
positions.
>I do not toatally understand your if (). In the third recursive call to qsearch,
>depth will be -3*PLY? What is m_currentDepth?
"depth" is the same depth that is used thoughtout the search to say how far it
is to the leaves of the search. So the normal search is called when depth is >
0, else the qsearch is called. The first call to qsearch will have 0 >= depth >
-PLY. The next will be -PLY >= depth > -2*PLY. And so on.
The m_currentDepth contains the current iterative deepening count. This goes 1,
2, 3... and so on.
The idea here is to cut the q-search at small search depths. As the iterative
deepening search depth gets bigger, more q-search depth is allowed.
>I would think, that for "normal" positions this is not needed.
True. It was added so that we could get to normal search depths without lots of
quiescence searching.
>>3. (this one may be new?) Cuts in the search if alpha or beta are in the mate
>>range, and the current ply is too deep.
>>
>>e.g.:
>>
>> // can't find better checkmates in more plies!
>> if( alpha >= evalCheckmate - ply )
>> {
>>#ifdef DEBUG_SEARCH
>> WriteDebug( ply, _T("s %d / deep %d\n"), ply, alpha );
>>#endif
>> return alpha;
>> }
>> else if( beta <= -evalCheckmate + ply )
>> {
>>#ifdef DEBUG_SEARCH
>> WriteDebug( ply, _T("s %d / deep %d\n"), ply, beta );
>>#endif
>> return beta;
>> }
>
>I am using one of the two.
>
> /* lowest possible score is -INFSCORE+ply */
> if (beta <= -INFSCORE+ply)
> return -INFSCORE+ply; /* cannot be worse than this */
> /* TODO: Use alpha cutoff in the same way? */
Interesting. I initially only did it with alpha, and then realised that it may
be possible with beta too.
>However, I think, this should only help when already a mate is found, and the
>task is to find a shorter mater.
Also true. But it is such a simple test that it makes negligible slow down in
normal searches. When there is a mate near, it can help a lot.
>Still, when I see your answer and your results, it seems, that I am doing
>something wrong :-(
Ah... the irony :) On the contrary, I would say that when I see the normal
results of YACE, it seems that *I* am doing something wrong :)
Cheers, Tim.
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.