Author: Robert Hyatt
Date: 09:10:52 08/05/05
Go up one level in this thread
On August 05, 2005 at 05:58:52, Tord Romstad wrote: >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 That is possible, but notice it is _not_ used nor compiled. I kept the code and occasionally experiment with it a bit. And others have requested it and done the same. So it occasionally shows up when I forget to remove it before releasing a new version... > >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. > OK... Bruce Moreland and I played with this quite a bit a few years ago, but there was certainly a significant risk... >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.