RE: [Bug-gnubg] The match and game data structure

[Ian Shaw]

> -----Original Message-----
> From: Jim Segrave [mailto:address@hidden 
> Sent: 03 July 2006 12:06
> To: Ian Shaw
> Cc: Øystein Johansen; address@hidden
> Subject: Re: [Bug-gnubg] The match and game data structure
> 
> On Mon 03 Jul 2006 (11:38 +0100), Ian Shaw wrote:
> > 
> > Jim Segrave Sent: 30 June 2006 16:11
> > > 
> > > Along with this, move the analysis and rollout contexts, if any 
> > > analysis or rollout is done to the match header. I think few 
> > > analysed matches have more than a single analysis context 
> or rollout 
> > > context used,
> > 
> > I don't think this is correct (but maybe I misunderstand 
> your point). I know people who will perform a quick 0-ply 
> rollout, and then maybe follow it up with a 2-ply rollout on 
> the most likely candidates.
> > 
> 
> Sure, but then all the analysis is either 0 ply evalutation, 
> 2 ply evaluation or one of two rollout contexts. In all, any 
> data on a particular move uses only one of 4 possible 
> contexts. In a 21 point match, we currently store perhaps 800 
> or so analysis contexts and output those 800 contexts to the 
> .sgf file. I'm proposing you store and output only 4 
> contexts, then 800 moves with a simple index to the analysis 
> context which is applicable. 
> 

I wholeheartedly support your aim, I just want to help ensure we don't 
accidently reduce the functionality by not considering some facet.

Specifying a miaximum 1, 2 or 4 possible contexts seems problematic to me, but 
we certainly do not require 1 per move, as at present.

You propose to index to the appropriate context. Is it then possible to have a 
record area for contexts, that you append to as the user defines new contexts? 
The context list would be similar to to a game record, in that it is 
potentially infinite, but is should always be no longer than the move list.

If you don't do this, you will simply have to limit the user to "Quick" and 
"Strong" settings, which might have a knock-on effect on the GUI design. 

-- Ian