Author: Robert Hyatt
Date: 18:06:14 04/06/04
Go up one level in this thread
On April 06, 2004 at 20:32:59, Dann Corbit wrote: >On April 06, 2004 at 17:05:18, Gerd Isenberg wrote: > >>On April 06, 2004 at 14:56:39, Robert Hyatt wrote: >> >>>On April 05, 2004 at 16:29:00, Gerd Isenberg wrote: >>> >>>>On April 05, 2004 at 15:51:43, Robert Hyatt wrote: >>>> >>>>>On April 05, 2004 at 15:02:56, Gerd Isenberg wrote: >>>>> >>>>>>On April 05, 2004 at 14:11:34, Robert Hyatt wrote: >>>>>> >>>>>>>On April 05, 2004 at 12:27:50, rasjid chan wrote: >>>>>>> >>>>>>>>On April 05, 2004 at 11:05:30, Robert Hyatt wrote: >>>>>>>> >>>>>>>>Thanks, but I don't need to test yet as you have tested ! >>>>>>>> >>>>>>>>I think using nodes searched should be good. >>>>>>>>If a move fails low with very few nodes searched, it probably >>>>>>>>mean being rejected easily, so sort low. >>>>>>>> >>>>>>>>Rasjid >>>>>>> >>>>>>>Correct most of the time. Sometimes a move will have a high node count just >>>>>>>because there are lots of checks and extensions. But I've been sorting by node >>>>>>>counts for 15+ years with good results, of course forcing the PV move to always >>>>>>>be at the top regardless of its node count... >>>>>>> >>>>>> >>>>>>I use node count per root move too. >>>>>>What about following "enhancement": >>>>>>If PV changes, to store (some) "previous" PV moves and to use them early after >>>>>>current PV move, regardless of their node counts? >>>>> >>>>> >>>>>It is worth testing. It didn't work for me in crafty or Cray Blitz, but it >>>>>might work for another program. I always had the best luck overall by just >>>>>using pure node counts... >>>>> >>>>>It helps the most when there is a "best" move that you won't find until deeper >>>>>depths. It will percolate up the list, iteration by iteration, so that it is >>>>>near the top on the iteration where it becomes best. I also use this >>>>>information in my parallel split/dont-split at the root adaptive algorithm in >>>>>Crafty... >>>> >>>> >>>>Yes, exactly my experience. Anyway i occasionally noticed a former PV move had >>>>low node count (e.g. a forced draw line) but a new PV move suddenly fails below >>>>draw score. Im such cases trying the "safe" drawline earlier may help to waste >>>>some time. >>> >>>Those are the cases that blow my adaptive "split/don't-split at the root" SMP >>>code. A repetition will produce a very small tree. If this is best, then most >>>of the remaining root moves might produce larger node counts, which makes it >>>look like they are all potential new best moves. I catch this, but not very >>>well... >> >>Another point i had problems with was during games, less node count due to >>(exact) hash hits from the previous search two plies before. Then finding >>something better which fails low next iteration - and the best move was searched >>at the end ;-( > >Why not store the last node count in the hash table then? Wastes memory. :)
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.