[gtp] gtp_v2draft

[Gunnar Farnebäck]

Adriaan wrote:
> Some comments on the 2nd gtp V2 draft:

Thanks. I'll just add a few random responses at this time. Well, maybe
it turned out to be more than a few. :-)

> [design,nitpicking]
> 2.8 Timing
> since, we have the possibility of "line numbers",
> I see no reason for the responses beiing sent back 
> in the same order as the requests were received.

Yes, this is somewhat redundant but I think it will make life simpler
on the controller side to have that guarantee.

> 3.2.1 move
> maybe "Resign" should be added as a valid move.

Pass and resign are troublesome. I decided to include pass in the
vertex entity but sometimes it doesn't make any sense like in a list
of handicap stones. Resign on the other hand only really makes sense
as a response from genmove, so I added that explicitly as a
possibility for that command.

> (in a subsequent section "Pass" was omitted)

Where? This is important to get consistent.

> 4.1.2 is too big, IMO.

Agreed. Most of it should be moved to section 8. (I wrote this before
I decided to have a comment section.)

> I think the PL[] and MN[] are (invisible) aspects 
> of the board state. PL should be made explicit,
> MN is less important.)

It's perfectly reasonable both to include or not include player to
move as a board state. I have rather negative experiences from other
protocols of having it as a board state, which is why I decided to
explicitly include color in the play and genmove commands. This is a
definitive decision for GTP version 2.

> Also, for setting up positions, there could be added a
> provision for one or more "forbidden" ko-locations to be
> kept in the board state.

Absolutely not. The only sane way to communicate ko information is by
playing through the game so far. If superko is used it's also the only
way.

> I noticed the rulesystem-section has been removed.
> I rather liked this independent setting of tt-like
> rule elements. It looked clear and more workeable
> than a "package deal" Japanese/Chinese/Goe/Ing/Igs
> kind of approach (which involves more semantics).

Yes, having separate rule elements is definitely the way to go.

> The timing commands should be moved to
> the tournament subset. 

Uh, that's where they are.

> IMO, The regression subset is not needed (for general use) 
> and should be consired an extension.

You're underestimating the value of using GTP for regressions and the
potential for sharing well defined test suites between programmers. I
would have excluded this except for the fact that I consider it
extremely important.

> Strictly speaking, loadsgf is not needed in the core set,
> but can be allowed there, because it is general enough.
> Every implementation will need some kind of file loading, eventually.

loadsgf is not in the core set for two reasons:

1. GTP and SGF don't really fit very well. SGF has a complexity and
   power of expression which isn't met by GTP. Maybe it will be in
   some future GTP version, but clearly not now.

2. loadsgf requires the controller and the engine to have a common
   filesystem. This is a reasonable assumption in regression settings
   but not in general. (Inline SGF is out of the question.)

> I don't see much need for renaming the V.1 "help" command
> into the ugly "list_commands". Semantics seem to have been
> tightened, but not changed.

A matter of taste apparently. I think "help" is more ugly.

> To me, place_free_handicap <--> set_free_handicap is confusing.
> My proposal: rename place_free_handicap into gen_free_handicap,
> which seems more in line with genmove, too.

I considered that alternative but I don't really like the "gen"
abbreviation. Does anyone else have an opinion on the naming of these
commands, or maybe a better proposal?

> 6.3.3 play/genmove
> "pass" and "resign" should both be valid moves
> for both the "play" and "genmove" commands

Pass is already valid. (See definitions of vertex and move entities.)
Resign is an explicit possibility for genmove but would it really make
sense for play?

> To facilitate automated playing, a command to
> report dead stones could be added.
> eg: "list_dead_stones B"

This can be done with the not yet documented "final_status_list"
command.

> loadsgf introduces a lot of implied semantics.
> The boardstate is changed heavily by sgfload.

Absolutely.

> SGF will change the MN-, PL- , KOlocation state
> in the engine, which were designed to be hidden
> in this GTP-draft.

What is the problem with these? If the engine wants to use move number
for some purpose it may change that state however it likes. I don't
see why the controller or the protocol should care.

Player to move is a non-issue by design.

"KOlocation" is implied by the "move history" board state. (There is,
by the way, no standard SGF property to manipulate ko state besides
move history.)

> 8.2.11
> [error] GMP uses a one-dimensional vertex
> coding scheme. 1 bit color + 9bits lineair addres, IIRC.

Yes, but it also associates this linear address with 2D coordinates
which are elsewhere used to define the fixed handicap placement.

> [politics] Why mention IGS and not NNGS, KGS ?

Whatever you think about the evolution of go servers it's undeniable
that IGS was first and I think it's safe to say that other servers
have followed its lead with respect to choice of coordinate
convention. A wise decision, of course.

Actually I'd like to know which servers do use this convention and
whether there are some which don't. I only regularly use NNGS, so my
knowledge is rather limited here.

Similarly I later have the comment "This fixed handicap placement is
compatible with the Go Modem Protocol and many go servers." This is
intentionally vague because I don't really know about IGS or other
servers than NNGS. Furthermore NNGS is only almost compatible. It
deviates, probably due to some obscure bug, for 2 and 3 handicap
stones on an 8x8 board. Any information about how other servers do
would be most welcome.

> 8.3.2
> IMO these are extensions, since it is unlikely
> that others (than gnugo) will ever use them.

Not so. There already are other people using them.

/Gunnar