Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Limited singular extensions. Anybody tried?

Author: Miguel A. Ballicora

Date: 11:23:01 05/18/01

Go up one level in this thread


On May 18, 2001 at 12:52:25, Gian-Carlo Pascutto wrote:

>On May 18, 2001 at 11:26:43, Miguel A. Ballicora wrote:
>
>>I am toying with the possibility to include (and learn about) some sort of
>>singular extensions in my program. I haven’t read any paper about that, just
>>the explanations given in this forum and long time ago in r.g.c.c.
>>Intuitively, the overhead would be huge and will hardly justify the benefits.
>>Now, the question is, has anybody ever try to implement a limited version of
>>singular extensions?
>
>I have done a full implementation of Singular Extensions for Crafty 18.9,
>based on the JICCA papers and comments from Robert.
>
>I am quite interested in how your implementation works, especially when
>dealing with some of the nastier cases (like fail-low on a fail-high
>singular move etc...)
>
>My code is freely available on request.
>
>>Like, triggering the algorithm only in certain positions or circumstances?
>>(there might be many possibilities to try, like there is an attack, evaluation
>>is unstable, mate threats, checks etc. etc.)
>
>How are you going to trigger the algorithm reliably? Mate threats and
>checks should already be extended without SE. 'An attack' is a too limited
>classification.

Of course, I just threw some ideas that might be considered to determine
if the algorithm it is worth to be triggered. In the case of mate threats
or checks to extend more than one ply (maybe), attack is not a proper term,
but statically it could be determined if I have pin pieces or attacked ones that
are not defended. If it is my turn, it will be worth it to see if my move is
singular, that means I am walking on the edge of a deep fall.

>When you check whether the evaluation is unstable, you are going to have
>to use quiescent searches to determine this. The actual evaluation is
>never stable in a real search tree. Doing those Qsearches is already
>going to add a lot of overhead.

I agree, it has to be statically determined.

>The idea of SE is to pick up things going on that are not detectable by
>static criteria. If you can come up with a reliable algorithm to trigger the
>check for SE, then you have made that same check pretty useless.
>
>>I just started to try and I found that my first try solved one problem much
>>faster.
>
>One problem...but how many were worse? My implementation has an overhead

I do not know, I have to do a serious test. Last night I just code
a simple case, I debugged it and I tried few positions (my toughest WACs) and
some positional to measure how the tree grew.
I know, I should be doing the test before asking but I was curious to know
the experience of other people.

>of nearly 2 ply. In the LCT2 which I used that lost many other solutions.

2 ply? ouch. My intuition was not bad. How does it play overall?

>
>>Did anybody try anything like it? Comments? Suggestions?
>
>I added two 'tricks' to my implementation:
>
>a) when you detect that several moves were singular but failed low
>after being extended, something interesting must be going on, and
>instead of continuing to extend/check/fail we just extend _everything_
>at this node. This is sort of a worst-case elimination.
>
>b) We can assume Crafty's 1st move is best in 92% of the attempts, and
>the best move is one of the first 5 in 99% of the attempts. If we do not
>get a move that disproves the singularity of the fail-high move within
>the first 5 moves we test, we assume it is singular and do not check the
>remainder.

The latter is a nice trick. Similar to R.H. suggestions some time ago to
use as negative extensions (reduce depth after several moves have been tried).
Kind of risky though.

What I did so far it is very simple. It is the most limited case I could
imagine: I triggered SE when in check (after it was extended already)
This is the pseudocode:

if (incheck) {
    depth +=1;
    if (1==moves_available) {
        depth += 1;            /* single response extension */
    } else {
        enable_SE = TRUE;      /* it will test a singular check evasion */
    }
}

generate_moves();
bestmove = loop_moves(&best);

if (enable_SE && best > original_alpha) {
     SE_alpha   = lower_of (original_alpha, best-PAWN_VALUE);
     secondbest = research_moves_but_bestmove (depth-2, SE_alpha, SE_alpha+1)
     if (secondbest > original_alpha) {
          best = research (bestmove, depth+1);
     }
}

return best;

Regards,
Miguel

>
>--
>GCP



This page took 0.01 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.