[Bug-gnubg] Changing rollout evaluations for later moves

[Jim Segrave]

I'm starting to work on implementing the changes to allow using a
different set of evalution parameters after some number of moves
during a rollout. For what it's worth, I'm starting coding with the
assumption that I will have 2 cube and 2 chequer eval contexts and a
separate eval context for handling the truncation point (it'll be
easier to remove things if they are deemed un-necessary than to add
them in). I hope to have the ability to set/display the additional
data in a rollout context during the course of this week. I belive the
code changes to use them will be the easiest part, so I'll do that last.

I've got a few questions :-)

On Mon 30 Sep 2002 (13:32 +0200), Øystein O Johansen wrote:
...
> The user must be able to set the two different evaluation classes and the
> number of plies whrer to change the search space.

I intend to add:

An option to enable/disable this feature

A setting for the number of plies at which we change. This must be at
least 3. It must be less than the truncation point.

Cube and chequer evaluation settings.

Questions:

1) Am I correct that the truncation setting is for the number of
   plies, not the number of turns?

2) We currently have separate evaluation contexts for each player. I'm
   not sure how these are set by the user.

3) Is there any useful purpose in having similar separate settings for
   the 'rollout late' contexts? It's easy enough to do so, the
   question is if it's needed.

4) should there be a user-settable evaluation context for the
   truncation point?

   As I understand it, when a rollout reaches that point, an
   evaluation is done and the cumulative rollout stats are updated
   based on that evaluation. So it would seem that getting this final
   evaluation right. At the moment, it appears to use the current 
   chequer evaluation context for the current player in the rollout
   settings. I doubt if we should change to the (presumably) less
   strict 'rollout late' settings, but I wonder if there would be any
   value in allowing this evaluation to be stricter than the starting
   one. For example, suppose you're doing a 1 ply rollout with a large
   search space (possibly going to 0 ply/medium after some number of
   moves). But when you hit the truncation point, would you gain by 
   doing a 2/3/4 ply huge final evaluation? 
   Again, from a coding point of view, it's easy. Having this many
   settable options might be overkill though.

5) Suggestions for default settings? Something like:
   Disabled, start at 5 moves, 0 ply, expert?

6) How does one test this? I assume we need a fair number of rolled
   out positions (with known rollout settings) which can be compared
   with the results of rollouts using this scheme. On my poor little
   laptop, I'm not going to be able to do anything extensive - a
   mid-game 1296 huge takes maybe 2 hours to complete.

7) How do we display the rollout settings in results? It's certainly
   important that reported results using this technique include the
   point where it activates and the settings for late decisions.

[snip code-specific very useful pointers]

> We may also discuss if it is neccesarry to add add an aecLateCube[2] and
> aecLateChequer[2]

See above. It's easy to add to the code, does it add any useful
functionality?

[snip more code-specific very useful pointers]

> What about the evalcontext for variance reduction aecVarRedn? Do we have to
> change this in some kind of way as well?

Looking at the code, which uses the current rollout eval contexts to
set the variance reduction eval context, it would seem silly not to
change the VR context when you switch to the rollout late evals. If
you don't, you might end up doing the VR evaluations more strictly
than the late rollout ones. But, as readers of the bug-gnubg list well
know, I am no expert in these areas.
 
> Now, what about the evaluation at the truncation point? Should this
> position be evaluated by the first or LateDecision evalcontext. How much
> will it cost in speed of rollout, and how much will gain to use the first
> (best) eval context?

It's no loss from the current single context. I would have thought
it's pretty minimal in any case. When truncation happens, it seems to
me that the amount of work done at that point is significantly less
than what would be done for a single move.

> For the GTK GUI:
> An "advanced rollout" button in the dialog. This button opens a new dialog
> where the user can set the limit and the evalcontext.

I'd still like to have as much as is reasonable on a single setting
screen, rather than a chain of menus.

-- 
Jim Segrave           address@hidden