Author: Jon Dart
Date: 14:11:49 08/03/99
Go up one level in this thread
On August 03, 1999 at 14:59:48, Scott Gasch wrote: >I am also limiting hte max depth of the qeval search to depth + 12 ply (6 >captures on each side). This causes moderate improvement in very "busy" >positions. I chose 12 because it is even (each side gets to capture the same >number of times) and I have rarely seen a chess game where the best course of >action is a string of 6 captures per side in a row. However, I am returning the >static "eval" of the position at this depth and I am worried that this may lead >to inaccuracy...? You bet. You can't just terminate the qsearch at a fixed depth (this was discussed at length in another thread). This may appear to work but sooner or later your program will make gross blunders, because bad scores at the bottom of the tree can be backed up clear to the root .. that's how alpha-beta works. > >I am still seeing poor performance, in qeval. In a typical "busy" middlegame I >am seeing about 4 million qeval calls with about 2 million "cuts" due to the >alpha rule (above) and about 200,000 cuts due to max depth exceeded. In these >types of positions it takes about 45 sec just to finish searching at 4 ply >depth! > Without more details, about all I can say is "you're doing something wrong.". If you have a reasonably good move ordering scheme (that puts good captures ahead of other moves) and are doing pruning as you suggest, your q-search should be pretty much under control. But an easy way to check it is to instrument things so that you get every move it tries printed out, indented by ply level. Run it at a shallow depth and see what it's doing. --Jon
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.