Re: [Bug-gnubg] Analysis/Evaluation Settings

[Joern Thyssen]

On Mon, Jan 20, 2003 at 07:10:45PM +0100, Holger wrote
> At 17:33 20.01.2003 +0000, Joern Thyssen wrote:
> >On Mon, Jan 20, 2003 at 05:49:35PM +0100, Holger wrote
> >> Since the move filters have been introduced I'm trying to find reasonable
> >> settings. Unfortunately, my computer isn't one of the fastest (P1-MMX 233).
> >> Which method should give the better result in terms of a compromise between
> >> speed and reliable results: Reducing the search space with the move filters
> >> or (presumably also reducing the search space ?) by reducing the speed
> >> setting?
> >
> >I think you have to experiment yourself.
> >
> >Try analysing the same match on a number of different settings and
> >record the time spent analysing (do a cold-start of gnubg to flush the
> >evaluation cache) as well a key parameters from the analysis.
> 
> OK.
> 
> I was hoping to avoid extensive trials as presumably one match doesn't do.
> At least it should be a rather long one.
> And then I'm no bg expert. I can say whether it takes too long for my
> taste, but I can't assess GNUbg's match evaluation. So I can't really
> decide when to stop reducing the search space. Maybe even static analysis
> is enough. I don't know. However, from comments on this list I believe it's
> safer with 2ply.

For many moves you certainly need 2-ply, but some moves are so obvious
that 0-ply is fine.

> And in order to understand how this speed option works: Could you relate on
> this, especially in conjunction with move filters? Are the settings for the
> move filters then halved for the next ply, or so?

The speed option has nothing to do with move filters.

Speed option:

A n-ply evaluation is an average over 21 n-1 ply evaluations.
A reduced evaluation averages over a reduced set of dice, e.g., a 33%
speed evaluation averages over 7 n-1 ply evaluations.

Move filters:

The move filters is just an generalization of the search space you know
from Snowie and previous versions of gnubg. With a search space you
typically haves the search tolerance and the search candidates. However,
with the move filters you specify everything yourself.

Assume you want to do a 2-ply chequer play evaluation: you may have a
move filter with the following definiutions:

Accept always 2 moves, and add 8 extra moves within 0.1 at 0-ply
Accept always 2 moves, and add 2 extra moves within 0.05 at 1-ply

So gnubg will start by evaluating all legal moves on 0-ply. The 2 best
moves and up to 8 extra moves (if they're within 0.1 from the best move)
is evaluated at 1-ply. The best 2 moves and up to 2 extra moves (if
they're within 0.05 from the best move) are evaluated on 2-ply.

This gives you add flexibility. For example, you can disable the 1-ply
filter: the best 2 moves and up to 8 extra moves are evaluated on 2-ply.

Or, you can set accept=0: gnubg will "add" up to 8 moves to be evaluated
at 2-ply. The best move is trivially within 0.1. If there is only one
move to be evaluated at 2-ply gnubg will skip the evaluation. This can
be used if you don't want to waste time on trivial moves, like an
opening 3-1. 

Jørn