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.