Author: Vincent Diepeveen
Date: 06:32:30 10/13/03
Go up one level in this thread
On October 13, 2003 at 09:29:33, Omid David Tabibi wrote: that doing check in qsearch is going to toast all your positions and score of course 100% at the mate in 4 and mate in 5. nothing as easy as to find mate in 4 or 5. or even 8 like just posted by Kim. which diep finds at a ply or 5 to 6 within 0:00 >On October 13, 2003 at 09:21:15, Vincent Diepeveen wrote: > >>On October 13, 2003 at 09:00:43, Omid David Tabibi wrote: >> >>>On October 13, 2003 at 08:44:36, Vincent Diepeveen wrote: >>> >>>>On October 12, 2003 at 12:16:42, Omid David Tabibi wrote: >>>> >>>>if you search 14 ply >>> >>>You count plies one way, Junior count's them another way, and Falcon counts them >>>in its own way. >>> >>> >>> >>>>with just 8 plies of mainline at a P3-733 then >>>>everyone can understand you forward prune, assuming a normal evaluation. >>>> >>>>the positions used for your ICGA article were all mating positions, >>> >>>LOL! You again show that you never read that ICGA article! >>> >>>In that article I used exactly the positions I mentioned here: >>> >>>138 Neishtadt positions, 879 ECM positions, 1001 WCS positions, and 434 "mate in >>>4" and 353 "mate in 5" positions. >> >>So kind of a 1000 mating positions. > >787 mating positions + 2018 non-mating positions. > > >> >>that proofs my point convincingly. > >Sure, the fact that 28% of the positions were mating positions convincingly >proves your point that they were all mating positions... (28% = 100%) > > > >> >>>:) >>> >>> >>>>now you suddenly use other positions????????? >>> >>>No, they are the very same positions. >>> >>> >>>> >>>>if so why? >>>> >>>>>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.