Author: Dieter Buerssner
Date: 06:56:39 04/10/02
Go up one level in this thread
On April 10, 2002 at 08:20:24, Steve Maughan wrote: >I came across this position. > >[d]6k1/6np/5ppq/pp1p4/3Pp1K1/4P3/P6Q/8 w - - > >I first encountered this position back in ~1987 in Eric Hallsworths excellent >newsletter - it was with regard to improvements in Richard Lang's engine. I >thought I'd see how todays programs compare. > >The whole point of the position is that after the obvious Qxh6 black can play >Nh5, trapping queen and allowing the Queenside pawns to promote. So the >position is a good test of how an engine handles trapped pieces and pawn >promotion. > >I tested the engines on my 1.5 GHz P4 with 96 Mb of Hash. I recorded the time >for the programs to show that Qh6 is negative and the time to suggest an >alternative (usually Qb8+). These are the results: > >Program Negative Alternative (Qb8) >Fritz 7 56 sec > 10 min >Crafty 18.14 2 sec 15 sec >Tiger 23 secs > 10 min >LGoliath 1.5 7 sec 24 sec >Junior 7 2 min 27 sec > 10 min >Monarch 5 secs 23 secs >Nimzo 7.32 3 secs > 10 min >Shredder 6.02 6 sec 1 min 55 sec >Yace 2 secs 11 secs > >As you can see many top programs struggle to suggest a better move. The normal >scenario is that they see the problem associated with Qh6 but then 'freeze' >while searching Qb8. Monarch has no specific knowledge in this position so I >was surprised that it did so well - null move will be disabled for most of the >search so maybe this is the problem with the other programs. I also wonder if >the others are doing Internal Iterative Deepening which *may* help (Monarch >does). My other thought is that maybe this position would be solved quicker if >the fail soft move was recorded along with upper bounds (alpha) since this would >give the search and may prevent the 'freeze'. Indeed very interesting. I think, here it is a combination of things, that can explain the behaviour. First of all null move. Lines like 1. Qxh6 Nh5 2. null b4 3. null a4 4. null This already "eats" 13 plies of depth for R=2. Of course, trouble will be smelled at some point, and lines will be researched with wider windows, and some null moves may not fail high again. But now, a very unfortunate interaction with adjusting alpha from lower bound values in the hash (when the depth was enough, of course) can happen. The hashtable will have many wrong scores, because of the null move issue. If you now trust the the low bound, things get crazy. If (for my engine) I do not adjust alpha, the line will be researched with the more open window, and the (wrong) null move lines will (at least partitially) not be there. So, with allowing to adjust alpha, and with null move (and some other search tuning details also have influence), Yace essentially fails here (but it can depend on "HT-luck"). I guess you used a version older than 0.99.56 for your times. I have seen this problem in various positions, and tried to do something about it (at the cost of a little bit search depth), but test results from games indicate, that it does not improve things in general. And to the "stuck with Qb8" problem. I think, with the correct window (so that Qb8 lies inside), the search tree here is just orders of magnitude bigger. So, when (because of the null move problem) the fail low comes at already high depth, the research will take ages. Regards, Dieter
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.