Author: Uri Blass
Date: 11:09:14 01/03/06
Go up one level in this thread
On January 03, 2006 at 14:04:17, Stuart Cracraft wrote: >On January 03, 2006 at 12:53:33, Uri Blass wrote: > >>On January 03, 2006 at 12:18:58, Tord Romstad wrote: >> >>>On January 03, 2006 at 11:49:05, Robert Allgeuer wrote: >>> >>>>On January 03, 2006 at 10:49:54, Maurizio Monge wrote: >>>> >>>>>What you said is surely true. >>>>>But what i find strange is that, IIRC, the only quite new technic in computer >>>>>chess that can be found in fruit is history pruning, everything else is just a >>>> >>>>History pruning was already in use in SmarThink and other engines before as >>>>well. If I am not completely mistaken history pruning was invented by Sergej for >>>>SmarThink. >>> >>>It is possible that Sergei introduced the name "history pruning", but the >>>technique itself is very old; certainly much older than SmarThink. >> >>You are right and Movei use it for some years. >>First public version of movei to use history based reduction was 07_99 >> >>I did not talk about it at that time but I used it and I am not going to be >>surprised if other also used it earlier. >> >> I no >>>longer remember where or when I heard about it for the first time, but it was >>>definitely not in this millennium. >>> >>>"History pruning" is a really bad name for the technique, by the way. Since >>>a long time, I have been advocating to rename it to "late move reductions". >>> >>>The word "history" is misleading because the technique can be implemented >>>without using history counters. >> >>In this case it is not history based pruning. >>I certainly use history counters but it is possible that I can improve it by not >>using history counters and using different conditions instead of them. >> >>Today I use combination of evaluation and history information to decide about >>reduction. >> >> >> I currently use a combination of null move >>>threat detection and evaluation data to make my late move reduction decisions, >>>and don't use history counters at all. This seems to work clearly better, >>>at least in my program. >> >>originally when I implemented it I had no condition about late move reduction >>but later I changed it and at least today I never reduce the first move. >> >>> >>>The word "pruning" is misleading because most people don't use the idea >>>to prune moves, but only to reduce the search depth. >> >>I agree that the word reduction is better. >>> >>>"Late move reductions" is a much more appropriate name, and does a better >>>job of explaining what the idea is about: Reducing the depth for the less >>>interesting moves late in the move list. >>> >>>Tord >> >>The idea is to reduce the depth of moves that you are almost sure that they are >>going to fail low. >> >>Uri > >And how do you decide this? You can decide about it based on combination of evaluation and history of the search and the place of the move in the move list. The implementation is different in different programs. Uri
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.