Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: The "same threat extension" as effective way to resolve horizon prob

Author: Robert Hyatt

Date: 10:50:49 10/01/03

Go up one level in this thread


On October 01, 2003 at 09:08:28, Sergei S. Markoff wrote:

>Hello!
>
>>What is the new quasy-Botvinnik extension if
>
>Well. I can inform chess community about one of my quasy-Botvinnik methods.
>I will be glad to receive your own experiment results and/or other
>considerations about this method.
>
>One of Botvinnik ideas is to determine attack/defence targets for further
>analysis of attack/defend trajectories. One of the way to find this target is
>null-move search. If the result of null-move search < beta we can see the move
>which fail low search bound. This move is a current threat. For example it's a
>threat of losing some piece.
>
>During the further search in this node we can found the defending move. The main
>idea is to extend the search if the threat moves on ply and ply+2 has the same
>target (capturing the same piece, promotes the same pawn). I can give you
>example if you want.
>
>It's one of simpliest way to use target info. But I think we can receive more
>improvement exploiting this idea.
>
>Best wishes,
>Sergei


It seems to me that Chrilly's paper on null-move search included this
idea as the "threat extension".  I have code that uses this, but I haven't
made it an official part of Crafty since the 9.x versions.  It did some good
things, but it is not free.  And it doesn't particularly work well with a
pure PVS implementation.

The basic idea was that if a move "fails high" (a real move) but the null-move
search fails low at the same position, then this "fail high" move is holding off
some threat.  IE I have a piece hanging and I can't save it, but a check will
push the loss beyond the search horizon.  By noticing that the null-move search
fails low (I lose the hung piece) but that playing move X fails high (saves
the hung piece) the search becomes suspicious that moves X is a horizon move
and extends the search enough to bring the loss back within the search
horizon.

The problem is that the null-move search has to fail "significantly low" and
the base idea within PVS would be to search with a lowered alpha/beta window
to see if it fails low _badly_.  You only do this test on a fail-high or PV
node, so it isn't horribly inefficient, but it is not free and after a lot of
testing, using Crafty, I eventually got rid of it.  I could probably supply the
code if someone wants to see it, and, as always, YMMV since I only tested it in
Crafty.



This page took 0.06 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.