Re: [Bug-gnubg] Differences in SGF parsing between gnubg 0.14 and 0.90

[Philippe Michel]

On Sun, 29 Aug 2010, dankwart.plattner wrote:

> I have some old sgf files created with gnubg 0.14 mingw. I recently opened 
> both with GNUBG 0.90 (my version:  0.90-mingw 20100220) and with a text 
> editor (see attached zip file).
>
> The first line (for the first game) reads:
> (;FF[4]GM[6]CA[UTF-8]AP[GNU 
> Backgammon:0.14-mingw]MI[length:5][game:0][ws:0][bs:0][wtime:0][btime:0][wtimeouts:0][btimeouts:0]PW[aakjaer]PB[You]RU[Crawford:Jacoby]RE[W+2]GS[M:25 
> 22 29 29 0 1 0 1 0 2 0 0 29 25 0.004441 0.000644 0.675724 0.097980][C:30 4 1 
> 1 1 0 0 1 2 0 0 0 0 1 1 0 0 0 0 0 0.182533 0.026467 0.000000 0.000000 
> 0.000000 0.000000 0.219323 0.031802 0.000000 0.000000 0.000000 0.000000 
> 0.000000 0.000000 0.000000 0.000000 0.040819 0.002980 0.000000 0.000000 
> 0.000000 0.000000 0.000000 0.000000][D:0 1 4 4 23 22 1 0 1 2 -0.568007 
> -0.046760 -1.232366 -0.181898]
>
> The interesting numbers are the 4 at the end of the GS[...] portion which 
> relate to checker play: 0.004441 0.000644 0.675724 0.097980. In the GNUBG's 
> analysis window (see attached jpg file) they show as -0,005 (-0,068) and 
> -0,676 (-10,153), which is quite different for 3 of the numbers.
>
> The same kind of differences show in the rest of the games, and in other 
> matches, as well, and seem to occur systematically. Needless to say, the 
> obscure all values dependent on these numbers as well.
> In general, GNUBG 0.90 reads what's in the sgf file only if the sgf file is 
> made with GNUBG 0.90. If the sgf file ist made with GNUBG 0.14, GNUBG 0.90 
> reads something different.
>
> Is there an explanation? Is this a bug? Any thoughts on this? Any possibility 
> to avoid this behaviour?

I think the explanation is that gnubg doesn't read the GS part of the .sgf 
file (or at least it doesn't use it). It recomputes the games and match 
statistics from the analysis of individual moves.

There are two consequences :

- rounding errors on the EMG numbers (1st and 3rd). 0.14 saved the moves 
analysis with only 4 decimal digits. For small errors like the first 
number it can make a difference. The problem must have been spotted at 
some point since 0.90 saves the same values with 6 digits.

- if you use a different match equity table, the MWC numbers can vary 
significantly. You probably use a different MET with 0.90 than you did 
with 0.14. That would explain the change in the 4th number when the 3rd is 
identical.

I don't think there is much to do about this. The accuracy problem has 
been greatly alleviated and it may be useful to have the MET name saved in 
the .sgf file (I think there is already a bug opened about this) but, 
regarding your 0.14 files, the information just isn't there.