Author: Omid David Tabibi
Date: 07:23:35 10/12/03
Go up one level in this thread
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.
True, I referred to commercial engines. HIARCS and King definitely do checks
everywhere in quiescence (with certain limitations of course), but I'm not
completely sure about Fritz, Shredder, and Tiger (Junior seems not to have a
quiescence at all, but it has a large set of extensions).
>
>>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,
[D]6k1/5p2/3P2p1/7n/3QPP2/7q/r2N3P/6RK b - - 0 1
If you do checks everywhere in quiescence, you should see this immediately.
After 1...Rxd2 2.Qxd2 all the rest of the moves are checks until you detect draw
by threefold repetition (maybe you've turned off repetition detection in
quiescence? or your max extensions limit is too shallow...). HIARCS finds the
move at the first iteration!
The following is Falcon's analysis (with checks enabled only at the first ply of
quiescence):
Falcon 0.0.3.5 running on GenuineIntel 733MHz 256MB:
depth time nodes nps score variation
6/10 0.16 16k 103k 3.22 1...h5f4
6/12 0.29 30k 104k 8.55 1...f7f5 1.d6d7 a2a8 2.d4d5
6/12 0.31 32k 106k 3.47 1...h5f4 1.d6d7 f4e6 2.d7d8q e6d
3.d4d8 g8h7
8/14 0.43 47k 109k 3.61 1...h5f4 1.d6d7 f4e6 2.d7d8q e6d
3.d4d8 g8h7 4.d8d4
8/17 0.89 99k 111k 3.50 1...a2d2 1.d4d2 h3f3 2.d2g2 f3f4
3.d6d7 f4d6
10/19 0.97 108k 111k 3.17 1...a2d2
10/19 11.42 1275k 111k 0.00 1...a2d2 1.d4d2 h3f3 2.g1g2 f3f1
3.g2g1 f1f3
12/21 11.54 1292k 112k 0.00 1...a2d2 1.d4d2 h3f3 2.g1g2 f3f1
3.g2g1 f1f3
14/23 12.04 1374k 114k 0.00 1...a2d2 1.d4d2 h3f3 2.g1g2 f3f1
3.g2g1 f1f3
16/25 14.07 1722k 122k 0.00 1...a2d2 1.d4d2 h3f3 2.g1g2 f3f1
3.g2g1 f1f3
>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).
Falcon doesn't manage to solve number 12 either.
>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.
That's true. Only recently I added checks in quiescence to the engine, and so
still haven't written a gen_checks() functions. However, the kind of attack
tables I use result in a very speedy generation of captures, which results in a
very optimized captures only quiescence. Adding checking moves will slow down
the engine considerably anyway, even if I write a good gen_checks()...
One thing I have to mention is that in the normal version I never check for
check evasions in quiescence. If the side to move is in check and doesn't have
any legal non-losing capture, I just return eval(). That's another reason why
the normal quiescence is so fast.
>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,
I wouldn't say so from a tactical point of view. Whenever the game turned
tactical, Crafty didn't have any chance against Falcon with checks in
quiescence. But Crafty did search deeper and played a better positional game. I
must also add that Falcon uses a huge number of different extensions (I think
only HIARCS has more extensions), and so maybe adding checks in quiescence on
top of them all isn't such a good idea...
>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).
In Falcon I conducted all the experiments I conducted on Genesis for the paper
verified null-move pruning, and got the same results. Plain R=3 was too risky
neglecting many tactical shots. I now use a modified version of verified
null-move pruning.
But maybe plain R=3 didn't work for me because I didn't have checks in
quiescence, and so it resulted in a very inaccurate search. The only program
I've heard which uses plain R=3 is DIEP, which does conduct checks everywhere in
quiescence.
>
>>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.