Author: Omid David Tabibi
Date: 09:16:42 10/12/03
Go up one level in this thread
On October 12, 2003 at 11:57:02, Vincent Diepeveen wrote: >On October 12, 2003 at 10:23:35, Omid David Tabibi 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. >> >>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. > >This simply is a matter of bad experimentation from your side. > >When you do check first ply in qsearch and no dubious forward pruning last ply >(your search depths are *very* big considering hardware) then at your 'testset' >that version will outperform any other version trivially with R=3, because it's >nearly all mating problems. You have said this again and again but that doesn't make it true. In my "testset" there are 138 Neishtadt positions, 879 ECM positions, 1001 WCS positions, and only 434 "mate in 4" and 353 "mate in 5" positions. Is this what you call "nearly all mating problems"? > >>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. > >You should test R=3/2 too when you forward prune that much. How do you know that I forward prune "that much"? > >> >>> >>>>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 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.