[Bug-gnubg] Suggestions wanted

[Jim Segrave]

I'm hoping the craziness at work will settle a bit and I'll have some
time to do some programming on gnubg.

I've been thinking about adding a way to save rollouts so they could
be extended later. As far as I can see, the rollout routine needs the
array of results, the stats it's been gathering, and the rollout
context being used, including the RNG seed. This is not a lot of
data. 

It shouldn't be too hard to split the rollout routine into an
initialisation routine used when not resuming a rollout and a rollout
routine itself which assumes that it's passed the accumulated data,
the rollout context and a count of games to be rolled out.

The idea would be that, when resuming a rollout, the current rollout
settings are saved for restoring later and the saved rollout data and
settings are read in. The rollout settings menu can be activated, but
only the number of games should be altered, since anything else will make
the results meaningless (in my opinion). 

So we need to save a small array of floats, a rollout context and the
rollout stats. This could probably be done in some one of the file
formats - I think .sgf files are extensible enough, but...

I've been looking at the XML docs and it strikes me that an XML file
is a good way to save this. It leads to a start on addressing another
often requested feature - the ability to create a database of saved
positions with their analysis, whether rollout or static evaluations.

With XML, we can (I think) save position data (easy), analysis/rollout
settings, analysis/rollout results, user commentary ( what kind of
position is this? a backgame, holding game, pure race) or whatever
categories a user might wish to define.

But that's a bit for the future. 

I'm looking for input on some things:

Assuming I can add some sort of save/restore rollout context and data,
am I correct that the amount of data to be saved/restored is
reasonably small - somewhere in the region of 50 odd values or so?

Is there anything intrinisicly wrong in my view of what needs doing:

1) modify the code in rollout.c to allow saving the current context,
   installing a new one and allowing the user to change the number of
   games to be rolled out.

2) ensuring that if a rollout is stopped/completed, after the user
   decides if they want to save the results, the old context is
   restored.

3) is it worth trying to restrict the user to only changing the number
   of games to rollout? It may be non-trivial to prevent changing
   anything else, although the results of any such rollout would be
   suspect in my opinion.

4) add a save button to the rollout window which allows some further
   dialogue - in particlar allowing the user to add some free text
   commentary about what they've save and why ("rollout of GOL reader's
   match cube decision on Feb 12 - I think we were right to take, in
   spite of what everyone says"). This would extend into the
   possibility of adding a more general 'Save position' command to
   allow users to build a database of interesting/embarrasing/instructive
   positions they have come across.

5) add a command/gui interface to allow selecting a saved rollout for
   extension. 

Does anyone have any opinions for/against using XML and a document
description to save this data. I'm tempted, because I wouldn't mind
getting some experience with XML, but that's not necessarily a good
reason. It does have the advantages that the data is sort-of
self-describing, which allows for the likelihood of changes in gnubg
which, with  a more restrictive format, might cause saved data to be
unusable with later releases, and the saved data is at least vaguely
readable and displayable from ordinary text tools. The current lack of
a copy button in the rollout and rollout stats window is an irritation
to me at least.

Again, thinking ahead, I don't know how easy it is to build a database
or other access method around something as free form as XML files or a
mega single file. If one were an author doing a new 501 positions book
or whatever, the very lack of structure might make this a less than
ideal method. This could just be my lack of experience with such
techniques, but I can't easily see how you store and reference XML
entities in an SQL database for example.

At any rate, I'm open to suggestions, criticisms, or best of all -
"Don't bother I'm already working on this"

-- 
Jim Segrave           address@hidden