Re: [Bug-gnubg] Measuring performance levels 2

[Jim Segrave]

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

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


-- 
Jim Segrave           address@hidden