Re: [gnugo-devel] gnugo / gGo interaction badness

[Gunnar Farneback]

Stuart A Yeates wrote:
> 1) Difficulties with boardsize.
>    When I set the boardsize to something that gnugo doesn't like (25x25)
> GGo and gnugo get confused as to the size of the board. gGo thinks it's
> playing on a large board and gnugo thinks it's playing on a small
> (19x19) board. The following interaction is typical:
> 
> --------------------------------------------------
> boardsize 25
> komi 5.5
> level 5
> fixed_handicap 9
> ? unacceptable boardsize

This is gGo's fault. It shouldn't ignore the error message from the
engine. (It may be possible to increase GNU Go's upper limit by
modifying the MAX_BOARD value in engine/gnugo.h and recompile. This
has not been tested, however. Higher value than 31 definitely won't
work but I'm unsure whether there are further limitations.)

> 2) Timing Issues
>    When playing with a relatively short amount of time, typically 1/3 I
> ALWAYS win on time (often about move 50-57). I'm a little mystified as
> to how the timing information works in GTP and there don't appear to be
> any explicit timing information in the GTP window or the gnugo
> commandline.

It doesn't. GNU Go 3.2 has no way to get timing information over GTP.
Recent development versions supports the timing scheme introduced in
GTP version 2 to the extent that it acknowledges the commands, but
then it silently ignores the information. GNU Go has some internal
timing support but it's not much documented or tested (see --autolevel
option and the code in interface/main.c and engine/clock.c if you're
really interested). This is an area where GNU Go needs work.

> 3) On small boards with a handicap gnugo seems to pass excessively for
> example:
> 
> ----------------------------------------------------
> boardsize 7
> komi 5.5
> level 5
> fixed_handicap 2

GNU Go thinks that black controls the entire board and that there's
nothing white can gain from playing. Not that I'd say it's wrong about
that but it certainly should try to thrash around for a while. This is
a known problem and probably not too hard to solve.

> and the following game, in which gnugo appears to object to the handicap 
> but still appears to think that there are stones on the board. For this
> game the gGo game window starts the board apparently empty :
> 
> ----------------------------------------------------
> boardsize 7
> komi 5.5
> level 5
> fixed_handicap 9

GNU Go 3.2 places four handicap stones (maximum on 7x7) while still
reporting an error. This doesn't make much sense and has been fixed in
recent development versions to comply with GTP version 2 which
explicitly says that the board state must not be changed by a failed
command.

/Gunnar