Re: [Bug-gnubg] TEST RESULT: Variance Reduction

[Jim Segrave]

On Mon 07 Jul 2003 (18:37 +0000), Joern Thyssen wrote:
> On Mon, Jul 07, 2003 at 12:49:33PM +0200, Jim Segrave wrote

I'm looking over a printed listing of rollout.c and I see what you
mean about the various local variables being deriveable from the
current values and their std's. Previously I simply went through the
routine and moved any variable which was altered during the rollout
loop out into the calling arguments so that it would be preserved. But
I now agree we need only the current values, the std's and the number
of games already rolled out. I'll start clearing that out tonight.

Then making MoveListRollout set up a list of moves in the arrays
passed in to RolloutGeneral will allow "parallel" rollouts and I can
look at using joint std's as a rollout stop parameter.

> > The
> > only other thing is that (technically at least) we should also pass in
> > a rolloutcontext per move to be decided.  Whether or not it is
> > sensible to compare rollouts of different moves using different
> > settings is sensible may be a legitimate question, but it seems to me
> > we shouldn't prevent it.
> 
> I can't see the purpose of using different rolloutcontexts, so I think
> we should stick with just one for the time being.  This will make the
> code much simpler.

It's probably not very hard to pass the appropriate context - that's
needed in the case of wishing to extend a rollout from a saved match -
you may not know exactly what the settings were - which set of move
filters for example or whether you split truncations. Saving and
passing the rollout context(s) to RolloutGeneral means that to extend
a rollout you need only set the number of trials higher than the
number already rolled out and it will automagically do the right
thing.

When rolling out multiple moves, each move record either has a stored
context (if the rc.et == EVAL_ROLLOUT, so we're extending the rollout)
or we use the current settings. 

-- 
Jim Segrave           address@hidden