Computer Chess Club Archives


Search

Terms

Messages

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

Author: Tord Romstad

Date: 06:27:09 10/12/03

Go up one level in this thread


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.

>Option 'b' produces almost the same tactical strength as option 'a', with a
>considerably lower overhead.

Interesting.  I have only tried options 'a' and 'c' myself, and always found
option
'a' to be significantly better (in games as well as test suites).  I should
probably
do some experiments with option 'b' as well.

>Only using checks in the first ply of quiescence, Falcon managed to solve almost
>all tactical positions of LCTII in less than 1 second,

Very impressive.  Gothmog (on an Athlon XP 2.4 GHz) solves the first 8 positions
in
less than a second, but needs 1:18 for number 9, 25 seconds for number 10, 25
seconds
for number 11, and doesn't solve number 12 at all (at least not within a few
hours).  Earlier
versions solved number 9 instantly, but the quick solution turned out to be
caused by
a bug: I had accidentally changed my single-reply-to-check extension to a
two-replies-to-check extension.

>outperforming the normal
>version (no checks in quiescence). But adding checks in quiescence (although
>only at its first ply) significantly slowed down the engine (from average of
>350kNPS to 150kNPS on my PIII/733MHz) and resulted in a worse branching factor.

You must have a very inefficient way of generating checks, I think.  I haven't
spent a
lot of time optimising check generation myself, and in my program the NPS drops
by
only about 15%.  It would probably be possible to push it below 5% with some
effort.

>So, it seems that adding checks in quiescence is great for solving tactical test
>suites, but not so for actual game play. The same goes for some of the
>aggressive extensions I tried; great for tactics, poor in games.
>
>I'd be interested to hear others' thoughts on this issue.

It seems like checks in the qsearch is one of those things that works well in
some
programs, and not in others.  Crafty, for instance, seems to do very well
without
any checks whatsoever, but for me the results without checks are clearly worse.

Other ideas that I have never been able to make work are recapture extensions
and
all sorts of nullmove pruning except plain R=3 (R=2, R=2.5, adaptive pruning and
verified
nullmove pruning are all clearly worse for me).

>I also considered using some form of static mate threat detection, independent
>of null-move search, but haven't found any interesting way to do so yet.

I have also experimented with static mate threat detection in the evaluation
function,
but it is very tricky to get it right.  Also, all minor bugs are likely to have
catastrophic
consequences (at least if you allow the evaluation function to return a mate
score when
the static mate finder reports a mate in n for the side to move).

Tord



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