[Top][All Lists]

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

Re: [gnugo-devel] reading connections

From: Gunnar Farneback
Subject: Re: [gnugo-devel] reading connections
Date: Mon, 08 Oct 2001 19:24:43 +0200
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Tristan wrote:
> I have written a program to convert my test suite 
> created from Golois games to gtp.
> here is the tar.gz file.
> connection tests are in connect.tst
> I also include capture.tst, global.tst and vie.tst
> the bug.sgf file are not yet in the test suite
> but are position where Golois played an obviously
> bad move...
> is this file format ok ?

It looks fine, except that some of the sgf files seem broken and I
believe all have a (smallish) systematic error. I tried capture.tst on
GNU Go and got these results:

  1 passed
  2 passed
  3 passed
  4 FAILED: Correct '1 H5', got '0'
  5 FAILED: Correct '1 S3', got '0'
  6 FAILED: Correct '1 O3', got '1 N2'
  7 FAILED: Correct '1 S3', got '1 S2'
  8 FAILED: Correct '0', got 'vertex must not be empty'
  9 passed
  10 FAILED: Correct '1 O11', got '1 P11'
  11 FAILED: Correct '0', got 'vertex must not be empty'
  12 FAILED: Correct '0', got 'vertex must not be empty'
  13 FAILED: Correct '1 D8', got 'vertex must not be empty'
  14 FAILED: Correct '0', got 'vertex must not be empty'
  15 FAILED: Correct '0', got 'vertex must not be empty'
  16 passed
  17 FAILED: Correct '0', got 'vertex must not be empty'
  Summary: 5/17 passes. 0 unexpected passes, 12 unexpected failures

Test case 8, e.g., looks like this:

  loadsgf Handtalk980824-1.sgf
  8 defend a2
  #? [0]

and the file Handtalk980824-1.sgf only contains

  (;SZ[1]AW[aa];C[captured(``) ])

which is obviously broken somehow.

Test case 11 is more subtle. The corresponding sgf file looks like

 move(fe):threatenToConnect(ed,dc) ])

This shows perfectly in Cgoban but when GNU Go reads it, it doesn't
realize that the size should 9x9 rather than 19x19. If I read the sgf
spec right, this file is actually incorrect, since SZ is a root
property and (citing from

root    Root properties may only appear in root nodes. Root nodes are
        the first nodes of gametrees, which are direct descendants from a
        collection (i.e. not gametrees within other gametrees).
        They define some global 'attributes' such as board-size, kind
        of game, used file format etc.

Thus the root node here contains the N, ID, BS, WS, GM, and FF
properties (most of which I assume are private properties) while SZ
appears in a non-root node. Just moving the SZ property should fix
this problem. I believe this is systematic and it holds for all sgf
files I've checked, although the 19x19 ones happen to be read
correctly anyway.


reply via email to

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