gnugo-devel
[Top][All Lists]
Advanced

[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

  (;N[Handtalk980824-1.gob]ID[Handtalk980824-1.gob]BS[0]WS[0]GM[1]FF[3]
  (;SZ[1]AW[aa];C[captured(``) ])
  )

which is obviously broken somehow.

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

  (;N[knippel.gob]ID[knippel.gob]BS[0]WS[0]GM[1]FF[3]
  
(;SZ[9]AB[ca][ab][cb][db][eb][hb][ac][bc][cc][dc][hc][ed][ce][ee][he][bf][cf][gf][hf][ag][cg][dg][gg][ig][bh][dh][eh][hh][ei]AW[ba][ea][fa][bb][fb][ec][fc][ad][bd][cd][dd][gd][hd][id][ae][be][de][ge][ie][af][df][ef][ff][if][eg][fg][fh][gh][fi][hi];C[captured(cb)
 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 http://www.red-bean.com/sgf/sgf4.html)

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.

/Gunnar



reply via email to

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