[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] prunning and sgf

From: Joseph Heled
Subject: Re: [Bug-gnubg] prunning and sgf
Date: Wed, 13 Oct 2004 07:47:42 +1300
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

No, I don't think I got it right. I definitely did not change the version number. I was able to load old sgf's, but probably the eval contexts are garbled. Perhaps someone (you? :) can give it a closer look and if you can clean it up. The problem is that eval contexts are all over the place, and they are not delimited in any way, which is quite a serious design flaw.

When will we move this unfortunate sgf to xml, and get something more 
(sgf can be made manageable in the same way, but only a big change will force us to do it ...)


Jim Segrave wrote:
On Tue 12 Oct 2004 (20:11 +1300), Joseph Heled wrote:

It means must put it at the end of the eval context? and I need to bump the version number? where? and what else?


The version number is taken from an #define in eval.h

Currently an evaluation appears as [abcd E data-from-eval ], where abcd
is the encoding of a move, see RestoreDoubleAnalysis() and
RestoreMoveAnalysis() in sgf.c for the sscanf() calls that process the
rest of the data.

An old style rollout looks like [abcd X data-from-rollout]
and a new style looks like      [abcd X ver 1 data-from-rollout
rollout-internal-state extended-rollout-context]

See RestoreExtendedCubeRollout() and RestoreExtendedRollout() for

These routines call CheckExtendedRolloutVersion() with a pointer to
the data after the 'X', which returns True if the version is 1, False
if not.
You'd need to (I think):

change SGF_ROLLOUT_VER in eval.h from 1 to 2
(you might want to change the name, since the version changes now cover more
than just rollouts)

Change CheckExtendedRolloutVersion() to return the version number (or
0 if there's no version info, i.e. a pre-extended rollout .sgf file),
rather than simply True or False if the version is/isn't == 1.
Then in RestoreExtendedCubeRollout() and RestoreExtendedRollout(),
you'd follow the code which restores the extended rollout stuff:

  if (is_current) {
    RestoreRolloutInternals ( pes, sz );
    RestoreExtendedRolloutContext ( &pes->rc, sz );

with something like:

  if (is_current >= 2) {
     routines to get your pruning data
Finally, in the routines which write out analysis results, add code to
put in the version number and the additional data you want to
save. See the bit in WriteRolloutAnalysis() which puts in the version
number there.

Jim Segrave wrote:

On Mon 11 Oct 2004 (19:39 +1300), Joseph Heled wrote:

I just realized that since pruning info is part of the eval context, my changes will break reading existing sgf files.

I can't remember, but I am sure this problem has come up before. Any ideas?

When I added the rollout extension things, I added some additional
additional fields to the rollout contexts and then put in a version
(defined in eval.h) to tell sgf.c whether or not to expect the extra
data. If handling an older .sgf file, I simply had to put in default
data (you can't extend a rollout from an older file). You might be
able to use the same approach if it's possible to put some reasonable
values in for the missing data. What I did was to put the string ver %d at the beginning of the analysis (when it is a rollout). sgf.c
checks for the presence of 'ver' followed by an integer and, if it's
found, it will expect extra data in the analysis.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]