On Mon 03 Jul 2006 (17:39 +0100), Ian Shaw wrote: > > > -----Original Message----- > > From: Jim Segrave [mailto:[EMAIL PROTECTED] > > Sent: 03 July 2006 12:06 > > To: Ian Shaw > > Cc: Øystein Johansen; [email protected] > > 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.
I would expect it to be an expandable array, so there would be no hard-coded limit on the number of different contexts -- Jim Segrave [EMAIL PROTECTED] _______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
