Re: [Bug-gnubg] Re: Naw..panic or teach me what I am doing wrong !!

[Jim Segrave]

On Thu 09 Jan 2003 (17:10 -0500), Gary Wong wrote:
> On Wed, Jan 08, 2003 at 09:45:49PM +0100, Jim Segrave wrote:
> > On Wed 08 Jan 2003 (18:32 +1300), Joseph Heled wrote:
> > > Can gnubg log the rollouts? I would like to analyze them with fibs2html 
> > > to see where the differences are?
> > 
> > I was thinking the same thing. It's easy to syslog the dice rolls, the
> > game number, player on move, cube action (although it's not important
> > here). The hard part is that all rollouts seem to use
> > BasicCubefulRollout() and that doesn't actually provide the chosen
> > move. 
> > 
> > I can change the call to FindBestMove() in this routine to return the
> > best move for non 0ply rollouts. Fixing it for 0 ply is a bit messy.
> > 
> > These patches may be a bit ugly and will assume the presence of
> > syslog() and openlog(), so it may not be usable under Windows.
> 
> I really like the idea of being able to log the rollouts, but I'm a
> bit doubtful about the use of syslog() to do it.  It's not particularly
> portable; on a multiuser system, there's a good chance the user won't
> have even have permission to read it; and it introduces yet another
> file format, which makes it tedious to write other programs to process
> the logged output.

Yep - I only chose it because it was very easy to add to the code -
one openlog comand and a couple of places to actually call
syslog. It's not the right idea for a production environment for all
the reasons you mention.
 
> How about we add some sort of command like "set rollout log <file>", and
> then write the results of the rollout to the specified file (if there is
> one) in SGF format as we go?  SGF can already handle most of the important
> data, and if we want to log other information that comes up we could either
> dump it to a C[] property or invent another random property to hold it.

I was idly looking at what it would take to write .sgf format files of
rollouts. I think it's not too hard to do. 

At the entry to BasicCubefulRollout, you have a board, score, match
length, and cube position, which is enough to create the .sgf header
(but I don't know how you convey the selection of Crawford & Jacoby
rules or disabling of cube usage. 

As I see it, we'd need to do some work in the following places:

FindBestBearoff() would need to return the move which is chosen so
that BearoffRollout() could generate the play record.

BasicCubefulRollout():

    needs to generate a new game header at entry with the position,
    cube, etc.
    
    needs to write double/pass double/take records when doing cubeful
    rollouts (where my patches currently syslog it)

    when it's doing the 0 ply evaluations for variance reduction, the
    code simply has an array of boards for all the possible dice
    rolls. Each one is updated by a call to FindBestMove(), but the
    chosen move is not recorded anywhere. We'd need to have an arracy
    of anMove arrays to match the array of boards so we'd know what
    move was selected

    For non-0 ply or non variance reduction, my syslog patches are the
    place to get move records

RolloutGeneral() needs to open the output file at the start and close
  the game record when BasicCubefulRollout() returns. Each exit point
  from the RolloutGeneral() needs to close the game file.


If this was all working, then we could look at something else which
would be useful - the ability to extend rollouts.

As far as I can tell, if we had the values of the rollout statistics
array being kept in RolloutGeneral, the number of games rolled out
so far, (would we want/need/be able to use the current RNG seed?), we
could add these to an sgf file or maybe come up with a file format for
saving this data if .sgf is not appropriate. Then RolloutGeneral could
be handed this file to initialise it's stats array and would be able
to extend an existing rollout. We would need to save all the relevant
settings for the rollout, so users didn't accidentaly extend a 0 ply
rollout with 2 ply or vice-versa. I think this might be a very popular
facility to have.
    


-- 
Jim Segrave           address@hidden