[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
badly.
The changes to FindnSaveBestMoves and FindBestMovePlied don't look too
hard at first glance.
--
Jim Segrave address@hidden
- Re: [Bug-gnubg] Measuring performance levels 2, (continued)
- Re: [Bug-gnubg] Measuring performance levels 2, Morten Wang, 2002/10/28
- Re: [Bug-gnubg] Measuring performance levels 2, Joseph Heled, 2002/10/29
- Re: [Bug-gnubg] Measuring performance levels 2, Joseph Heled, 2002/10/29
- Re: [Bug-gnubg] Measuring performance levels 2, Morten Wang, 2002/10/29
- Re: [Bug-gnubg] Measuring performance levels 2, Joseph Heled, 2002/10/29
- Re: [Bug-gnubg] Measuring performance levels 2, Joseph Heled, 2002/10/29
- Re: [Bug-gnubg] Measuring performance levels 2,
Jim Segrave <=