Author: Robert Hyatt
Date: 19:35:20 10/21/03
Go up one level in this thread
On October 21, 2003 at 17:21:14, Omid David Tabibi wrote: >On October 21, 2003 at 14:43:45, Robert Hyatt wrote: > >>On October 21, 2003 at 11:53:02, Tord Romstad wrote: >> >>>I don't run my engine through WAC very often, but before releasing a new >>>version (which I will do within a couple of days) I run the whole suite as >>>a sanity test. This time, the following position made me worried: >>> >>>[D]8/8/2Kp4/3P1B2/2P2k2/5p2/8/8 w - - bm Bc8; id "WAC146"; >>> >>>Previously, my program had no problems with this position. The new >>>version, which is the first one to include tablebase support, prefers >>>Bd3 instead of Bc8. At ply 21, the score is +12 for white. When I >>>disable tablebases, the program plays Bc8. >>> >>>Does Bd3 also win, or should I look for yet another bug? >> >>Bd3 is a second solution. It has been in my version of the test since >>I first found this myself, years ago. >> >> >>> >>>One of the hardest positions in WAC for my engine is number 163: >>> >>>[D]5rk1/2p4p/2p4r/3P4/4p1b1/1Q2NqPp/PP3P1K/R4R2 b - - bm Qg2+; id "WAC163"; >>> >>>On a Pentium IV 2.4 GHz, I need 11 plies and 1m53s to find the winning move. >>>The problem is to find the line 1... Qg2+ 2. Nxg2 hxg2+ 3. Kxg2 Bf3+ 4. Qxf3 >>>exf3+ 5. Kg1 Rf5! followed by Rfh5. Without nullmove pruning, this position >>>is solved within a few seconds. >>> >>>This is rather annoying, as I have lost more games than I would like on >>>the ICC because of missing similar tactics. Are there any inexpensive >>>tricks to help me solve this kind of positions more quickly? >> >> >>I pick this up at depth=9, time = 2 seconds (using one cpu on my dual 2.8 >>xeon box). All I can guess is that I do extensions a bit differently, >>somehow, or the adaptive null-move R=3~2 idea helps a bit. > >I would attribute it to Crafty's extensions. You allow more than one ply of >extension at a time (e.g., mate_threat + checking_move) while most programs >don't practice it. Additionally, you also do one reply extension, which in this >position certainly helps. > >Based on their analysis, it seems that most commercial engines prefer to keep >the branching factor smaller than to extend intensively (Hiarcs is the big >exception of course). After some tests I limited the extension to one ply at a >time in my engine, and also removed one reply extensions. It seems that the >overhead is too much in most cases to justify the profit (especially if you >already have some form of checks in quiescence). Actually I don't do that. I limit extensions at any one ply to no more than 1.0 plies. The only thing I allow is that multiple extensions might fire that separately are < 1.00, but they can sum to 1.00. But at any one ply I _never_ allow more than 1.00 plies of extensions to fire. However, my "give-check" extension fires at ply=N, and the one-reply extension will fire at ply=N+1, so that might be a bit more than some do, if you don't do "give-check" but do use "out-of-check". > > >> >> >>> >>>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.