Newbie's questios about qsearch

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

elcabesa
Posts: 855
Joined: Sun May 23, 2010 1:32 pm

Re: Newbie's questios about qsearch

Post by elcabesa »

Code: Select all

int Evaluate()
{
    int v = EvaluateFromWhiteViewpoint();
    return (sideToMove == White) ? v : -v;
}
sideToMove is the side to move (obviously) after you did the actual move in the search, not the side to move at the start of the search!!

so if it's white turn and you are searching e4 e5 side to move is white, but at depth 3 e4 e5 Nf3 side to move is black :)

I hope this could help you.
diep
Posts: 1822
Joined: Thu Mar 09, 2006 11:54 pm
Location: The Netherlands

Re: Newbie's questios about qsearch

Post by diep »

And yes searching quiet checks in the qsearch is useful. After some testing I came to the conclusion that 1 quiet check is best (I'm sure this is all well known, Fruit does it, and probably Cray Blitz did it in the 80s already).
Actually I was promoting doing checks in qsearch publicly at rgcc in 90s and also in CCC and on one else was PUBLICLY supporting that - basically it was a number of private and commercial engines actively giving checks and doing check evasions in qsearch. Not all top engines were doing it, crafty for example also didn't do evasions. Crafty's mainline regurarly captured further after being checkmated. I remember discussions here in CCC where Bob mentionned he had tested it again for crafty but didn't get it to work. So it only got more popular when 1 open source program doing it, Fruit, also started to do it. So what you write here is quite recent 'public' knowledge...

I wouldn't be amazed if for the ultimate beancounter concept there is between and/or replacing the last few plies and qsearch a phase of doing very little, yet doing some checks, and qsearch only being positive captures... ..in the end no engine has a magnificent solution for the last few plies of search.
diep
Posts: 1822
Joined: Thu Mar 09, 2006 11:54 pm
Location: The Netherlands

Re: Newbie's questios about qsearch

Post by diep »

pocopito wrote:Hi all

Just two questions related to qsearch, trying to get my ideas clear. Let's assume we have a qsearch like the one from Bruce Moreland's site:

Code: Select all

int Quies(int alpha, int beta)

{
    val = Evaluate();
    if (val >= beta)
        return beta;
    if (val > alpha)
        alpha = val;
    GenerateGoodCaptures();
    while (CapturesLeft()) {
        MakeNextCapture();
        val = -Quies(-beta, -alpha);
        UnmakeMove();
        if (val >= beta)
            return beta;
        if (val > alpha)
            alpha = val;
    }
    return alpha;
}
The questions are:

1- How should work the sign of the score returned by the Evaluate function in order to Quies to work properly? (Be positive or negative depending on the side to move? The same sign always for the same side?...)

2 - An engine with an alpha-beta search that calls Quies in the leaf nodes, playing white being set at 1 ply depth, after the moves 1-Nc3, d5, should be capable to avoid the at one ply best Nd5?

Thanks in advance regards

E Diaz
the same sign for the same side basically is not the popular concept as it requires treating both sides in a different manner. One side needs to maximize its chances then and the other guy minimize its chances.

Therefore more popular is negamax. I'm sure some wiki is explaining what negamax is. It means that you maximize everywhere your chances and only when you get from your opponent something returned you put a minus sign in front of it, because what's the best for your opponent is the worst for you...

With negamax, alpha flips to -beta and beta to -alpha.

So this obvious means that if you try at the top of your search the qsearch, that it is a positive call, as it is for the same side to move that you call it. No negamax gets used there.

Your next question is a lot harder and it is total open to interpret theory there. Historically the chessprograms just focussed upon material maximization in the quiescence search.

The idea is that if you do a 3 ply depthlimited search that suddenly after
1.Nc3,d5 2.Nxd5 that it seems as if d5 was a bad move as white can capture it ,whereas in reality this is a horizon effect.

So we then give the opportunity to react onto the position by trying good captures.

Yet trying to avoid this horizoneffect has another sideeffect which is that for relative little effort a program can get tactical stronger a lot.

In fact the material considerations were so important years ago that a lot more was tried in quiescence search. Some even nullmoved there trying to detect tactics and so on. Obviously checks also quickly were tried there.

What basically survived is doing good captures in quiescence search as well as good checks and check evasions. Most posters here because of fruit showing them, prior to that the 'forums' weren't believing much into doing checks, though most stronger chessprograms were doing it.

The real question for the 21th century with respect to quiescence search is what we really want to achieve there.

Do we just want to avoid the short term horizon-effect caused by the LAST move played? Do we just want to get the position more quiet and solve basically all horizoneffects we might suffer from? Or do we want to pick up more tactics and how important are tactics nowadays or do we also want to catch positional moves? It's all open questions with no clear answer.

The reason to ask this is because NOWADAYS not seldom positional moves swing the evaluation a lot more than capturing a pawn, especially the famous Be3xa7 capture from white, with black responding b6 after which the a7 bishop is hung :)