[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] Measuring performance levels 2

From: Jim Segrave
Subject: Re: [Bug-gnubg] Measuring performance levels 2
Date: Wed, 30 Oct 2002 09:58:12 +0100
User-agent: Mutt/1.4i

On Wed 30 Oct 2002 (12:08 +1300), Joseph Heled wrote:
> Hi,
> We seriously need to consider changing the move selection pruning to something
> more configurable but with good defaults. Here is my suggestion.
> For each ply N, you can specify the amount of filtering of 0,1, ..., N-1 plys.
> Each filtering level is given by M, T and M(T). M is the maximum number of 
> moves
> to keep. M(T) is the number of additional moves to keep, assuming they are 
> more
> than T from the best move.
> (I am talking equity here, assuming usage of 'gammon weights')
> So, for example, 
>   Ply 1:  8,0,0   -- evaluate top 8 0ply moves by 1ply.
>   Ply 2:  2,3,0.1   -1,0,0  -- evaluate between 2 to 5 moves as given by 0ply.
> Don't use 1ply.
>   Ply 3: not sure, I hardly use that
> Comments and volunteers?

Various comments:

It's not too hard to implement adding it to an evalcontext. For the
GTK interface, I think that every evaluation choice uses a common
widget and a common function to create and display the widget. For the
textual interface, again it shouldn't be any major problem.

It is a (potential) barrier to new users - the current configuration
for analysis/evaluation/rollouts is intimidating enough, although the 
presets perhaps make this not so bad.

>From your examples I take it that M is not a maximum, it's a minimum -
e.g. keep at least M moves (assuming that many legal moves exist). Or
have I misunderstood what your meaning is?

I think having a minimum number of candidates to keep is a useful
feature and probably better than the current ad-hoc setting of the 0
ply threshold to max (.25 (or .24), search tolerance). There are
samples of near-bearoff positions where 0 ply misses the best move

The changes to FindnSaveBestMoves and FindBestMovePlied don't look too
hard at first glance.

Jim Segrave           address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]