Re: [Bug-gnubg] comparing pruning version with previous ones

[Jim Segrave]

On Mon 18 Oct 2004 (10:54 +1300), Joseph Heled wrote:
> 
> 
> Jim Segrave wrote:
> >On Fri 15 Oct 2004 (20:11 +0200), Jim Segrave wrote:
> >
> >>On Thu 14 Oct 2004 (18:52 +0200), Renzo Campagna wrote:
> >>
> >>>Hi all, i've installed both archives (new setup & pruning extra), but my
> >>>analysed files from previous version of GNU BG now are not readable
> >>>correctly (wrong numbers in analisys summary, all values are 0 in 
> >>>analisys
> >>>panel).
> >
> >
> >I just ran 297 matches containing 2211 games which were analysed with
> >earlier versions of gnubg - the .sgf files date from April until
> >September of this year. I used a previous version to read each .sgf
> >file and output the match statistics and the statistics for each
> >individual game. I then read the same .sgf files with a pruning
> >version and collected the same output.
> >
> >Of the matches, 14 had differences in the output, all of which were
> >changes in assigning Missed doubles as being above or below the
> >doubling point. 
> 
> Thanks. Can you spot check that those were borderline cases?

I'll have a look inthe next day or so. The number and total cube
errors stay the same, so it's very likely a change in how gnubg
decides which threshold the error lay in.

> >While I haven't done a complete walktrhough of all the .sgf files,
> >when I do spot checks, the analysis windows show the same values with
> >the older version as the new one. So I don't see any problem with
> >reading .sgf files from older versions of gnubg.
> >
> >If you have one which seems very wrong under the new version, please
> >mail me a copy.
> >
> >I am updating the .sgf file format to account properly for pruning and
> >the expectation that reduced evaluations will shortly be discarded in
> >favour of just pruning.
> >
> >
> 
> Not sure what you mean? 'reduced' is already 'ifdefed' out. I just did not 
> remove it from the sgf since that would *surly* break old sgf's.
> And the pruning data is in the new sgf's. So, what do you actually want to 
> do?

I've just checked in code which supports building a gnubg with or
without reduction (although I assume it will go shortly). A version
with pruning, with or without reduction code, should be able to read
any .sgf file written by any other version, although it will only
write it's own version. Each eval in the sgf file has a version
attached:

no version - prior to extending rollouts
ver == 1   - rollout extensions, reduction, no pruning
ver == 2   - rollout extensions, reduction, pruning - I expect that
             this should never occur, but I thought I'd cover it, as
             you *could* build such a version
ver == 3   - rollout extensions, no reduction, pruning.

when gnubg reads an sgf, it looks for a version string and uses the
appropriate sscanf to get the data which is present (ver 3 has no flag
for reduction, ver 1 has no flag for pruning, ver 2 has flags for
both)

A build using today's source, with reduction enabled, would write ver
2 evals in the sgf file and could read ver 0, 1, 2 or 3 .sgf files

A build using today's source, with reduction not enabled, will write
version 3 files and can read any of the others.

I'd like next to remove reduction (and use the tab for it in the eval
configuration windows to enable/disable pruning, but I wanted to do
one thing at a time.

Version 2 and 3 files will no longer write the four floats
(arUnused), so we get the space back that used to be there.

-- 
Jim Segrave           address@hidden