Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: To check or not to check, this is the quiescence question

Author: Omid David Tabibi

Date: 07:41:15 10/12/03

Go up one level in this thread


On October 12, 2003 at 10:01:39, Uri Blass wrote:

>On October 12, 2003 at 09:47:39, Uri Blass wrote:
>
>>On October 12, 2003 at 09:27:09, Tord Romstad wrote:
>>
>>>On October 12, 2003 at 06:32:25, Omid David Tabibi wrote:
>>>
>>>>Recently I conducted some extensive experiments with two versions of Falcon, one
>>>>with checks in quiescence and one without. Falcon already has lots of
>>>>extensions, but adding checks in quiescence resulted in a significant boost for
>>>>tactical strength.
>>>>
>>>>I tested the following options:
>>>>
>>>>a) checks everywhere in quiescence
>>>>b) checks only in the first ply of quiescence
>>>>c) no checks in quiescence
>>>>
>>>>Option 'a' was ruled out after some testing, as it resulted in a total explosion
>>>>of quiescence search. I tried controlling it in some ways, but still the
>>>>overhead was considerably more than the benefit. It seems that The King and
>>>>HIARCS are the only engines using this method.
>>>
>>>These are not the only ones.  I am fairly sure Diep searches checks everywhere
>>>in the
>>>qsearch, and Gothmog (my engine) also does.
>>
>>
>>If you searches checks every where in the search then by definition
>>you find the draw at ply 1 if your program has stalemate detection in its
>>evaluation.
>>
>>[D]r7/8/8/8/8/PPPP4/2QP4/k6K b - - 0 1
>>
>>If it does not detect the draw at depth 1 even with checks everywhere then we
>>have different definition of everywhere so you should expalin your definition of
>>everywhere.
>>
>>extending escape to checks everywhere is not enough to search checks everywhere
>>and you need also to generate all possible checks everywhere.

Of course. By checks in quiescence I mean all checking moves and check evasions.

In the normal version I have neighter checking moves nor check evasions.


>
>or at least everywhere when the score is not above beta so you cannot return
>beta without generating checks and captures.
>
>Maybe this was not a good example but imagine a case when you sacrifice a piece
>to force perpetual check.

You mean something like LCTII pos. 9:

[D]6k1/5p2/3P2p1/7n/3QPP2/7q/r2N3P/6RK b - - 0 1

Even with checks only at the first ply of quiescence Falcon finds 1...Rxd2 in
less than one second. HIARCS which conducts checks everywhere in quiescence
finds this at the first iteration.


>
>When you search sacrificing the piece the score is not above beta so you need to
>search check for the side that sacrificed the piece the opponent has many
>replies and you need to search all of them.
>
>again the score is behind beta after the escape of the opponent so you need to
>generate all checks and it continues.

I think that's the way HIARCS conducts its checks in quiescence without blowing
off the quiescence...


>
>I can imagine practical cases when it is going to cause you million of millions
>of nodes in the qsearch.
>
>Espacially the queen may practically give 50 checks in a row in queen endgame
>without stalemate when you cannot return beta because the side that give checks
>is always worse relative to beta.

That's what happened when I initially added checks in quiescence. I was
wondering why in a quiet pawn ending suddenly so many checks are done until the
max depth of 64 is reached! (a queen promotion and subsequent checking sequences
were the cause)


>
>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.