Author: Ulrich Tuerke
Date: 07:11:00 04/23/01
Go up one level in this thread
On April 23, 2001 at 09:48:40, Dann Corbit wrote: >On April 23, 2001 at 09:45:45, Ulrich Tuerke wrote: > >>On April 23, 2001 at 09:34:20, Robert Hyatt wrote: >> >>>On April 23, 2001 at 05:52:00, JW de Kort wrote: >>> >>>>Dear friends, >>>> >>>>I have added a qsearch to my program and as a result the number of nodes in my >>>>search has exploded. Sometimes the program searches ten times as much nodes in >>>>the qsearch than in the regular search. Can anybody give me some advice on >>>>methodes i can use to limit the number of nodes in the qsearch? >>>> >>>>Thanks in advance. >>>> >>>>Jan Willem >>> >>> >>>A simple idea works well: >>> >>>When you enter a q-search node, if the current score is (say) a queen below >>>alpha, then capturing a pawn or piece is not going to bring the score back up >>>to alpha. Those captures are useless to examine.. >> >>I think that this is just what I had suggested in my reply, but you have >>explained far better why this should work. >> >>You say "useless to examine" . After all, this algo involves some kind of >>forward pruning and there is a certain risk in missing some tactics. >> >>However, I admit that this trick appears to be reasonably safe. I guess, >>everybody is doing it. >> >>Nevertheless I had observed that in some rare cases, a test position will be >>solved later (i.e. in a higher iteration) as a consequence of this trick. >> >>Do you agree ? > >Just like NULL MOVE or any selective element for searching, it will cause some >problems to be solved more slowly. However, I suspect it will cause *most* >problems to be solved faster. That is the way it works with every good idea. Completely agreed. The above mentioned risk arises essentially if you have chosen your cut threshold (too) close to alpha.
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.