Author: Tord Romstad
Date: 02:58:52 08/05/05
Go up one level in this thread
On August 04, 2005 at 21:49:45, Robert Hyatt wrote: >Not sure what you are reading. singular.c has not been a part of any normal >distribution, as I have never found satisfactory settings that made it work >effectively. What? The Crafty source code on my machine does contain a file named singular.c, and I am fairly sure this is a normal distribution. It was downloaded by FTP from ftp.cis.uab.edu. The version number is apparently 19.9 On the other hand, the file is apparently not used by default. The whole file is wrapped in a big #if defined(SINGULAR) ... #endif form, and SINGULAR isn't defined. >I really have not seen any info on "history pruning". I'll try to see what I >can find unless you can provide an explanation... You certainly know the idea, just not the name "history pruning" which has become popular over the last couple of years (I am not sure what it was called before). It's a rather unfortunate name, I personally prefer the name "late move reductions". The idea is based on the simple observation that in a program with reasonably good move ordering, if the first few moves in a non-PV node fail low, it is very likely that the search will fail low at this node. Late move reductions take advantage of this observation by searching moves late in the move list with reduced depth. In most implementations, if one of the reduced depth searches return a fail high score, the move is re-searched with full depth. Of course doing this without any extra conditions is too risky. There are some moves you simply cannot risk searching with reduced depth, even if they appear late in the move list. Obvious examples are checks, captures, promotions, and possibly passed pawn pushes. If you evaluate internal nodes, it could also be interesting to avoid reducing moves which dramatically increase some component of the evaluation function. Finally, as a last safety measure, many programs check the history counters of the moves. If a move has failed high very frequently in the past, it might be best to search it with full depth. This last condition is the reason for the name "history pruning". An enhancement which works well in my engine (worth around 20 Elo points, I think) is the following: At the node directly following a reduction, if the null move fails low, and the moving piece in the move that refuted the null move is the same as the moving piece in the reduced move, immediately stop the reduced depth search and re-search with full depth. As always, YMMV. It seems that this trick doesn't work well in most programs. 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.