Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Move ordering at root

Author: Dann Corbit

Date: 17:32:59 04/06/04

Go up one level in this thread


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?




This page took 0.01 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.