Re: [Bug-gnubg] multiply evaluation code comments

[Joern Thyssen]

On Wed, Sep 22, 2004 at 12:57:36PM -0700, David Montgomery wrote
> Hi,
> 
> At GamesGrid we're about to put up a 2-ply bot.
> In reviewing some of the settings I concluded
> that some comments in eval.h were misleading.
> 
> Please correct me if I'm wrong.
> 
> For movefilter a comment says "always allow this 
> many moves. 0 means don't use this level, since 
> at least 1 is needed when used."  Maybe 0 still 
> implies to not use this level, but I see that
> the default filter uses -1 and FindnSaveBestMoves
> tests < 0, not <= 0.  
> 
> In fact, looking at the default filter I'm not 
> sure what 0 means for Accept.  0 is used for the 
> even ply, and -1 for the odd ply.  To be honest,
> I don't know why Accept isn't always -1 on the
> diagonal, since once you've evaluated at the
> max ply we are going to, there's no need to filter.
> 
> For evalcontext a comment says about nReduced:
> "this will need to be expanded if we add support 
> for nReduced != 3".  In fact, nReduced 2, 3, and
> 4 (and 0) all appear to be supported, and up to
> 7 could fit in the bitfield.

accept=0 is a valid value: for example, with accept=0 extra=4 threshold=0.1
you get one move and up to 3 extra moves within 0.1. Note that gnubg
will *not* evaluate the move at the next ply if only move is found.

Had you used accept=1 extra=3 threshold=0.1 you force evaluation of the
top move at the next ply. 

For chequerplay decisions by a bot, I suggest accept=0. For example,
there is no need to evaluate an opening 3-1 at 2-ply. You ensure that by
using accept=0 extra=n threshold=t for the 0-ply filter.

J?rn

pgp6XeeA19xO5.pgp
Description: PGP signature