Computer Chess Club Archives




Subject: Re: Move ordering at root

Author: Robert Hyatt

Date: 12:51:43 04/05/04

Go up one level in this thread

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.
>>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

This page took 0.04 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.