Hi,
Shouldn't the GTP protocol include setup commands such as those found in SGF to add black or white stones to the board, clear points, AB, AW, AE (PL is probably redundant)? It would help to create a position and ask the engine to generate a move from there.
Of course, this could be done with the loadsgf command but there are times when there is no sgf file. I would prefer to have these commands in GTP rather than writing a temp sgf file just for that purpose.
Also, the current GTP spec on laodsgf is not explicit about this: are all setup nodes and properties allowed and taken into account when replaying the game record?
Marco Scheurer Sen:te, Lausanne, Switzerland http://www.sente.ch
Marco Scheurer wrote:
Shouldn't the GTP protocol include setup commands such as those found in SGF to add black or white stones to the board, clear points, AB, AW, AE (PL is probably redundant)? It would help to create a position and ask the engine to generate a move from there.
won't the `play' command work? i often setup positions this way when debugging gnu go.
Also, the current GTP spec on laodsgf is not explicit about this: are all setup nodes and properties allowed and taken into account when replaying the game record?
currently there seem to be no description of `loadsgf' in the latest specification draft, but i think that gtp shouldn't interfere with sgf. i mean, it shouldn't specify how to load an sgf file since sgf specification already describes that and i can see no point in changing its policy. i think that engines should load sgf files the same way, no matter asked by `loadsgf', through command line or by any other means.
Paul Pogonyshev
On Sunday, January 19, 2003, at 11:07 PM, Paul Pogonyshev wrote:
Shouldn't the GTP protocol include setup commands such as those found in SGF to add black or white stones to the board, clear points, AB, AW, AE (PL is probably redundant)? It would help to create a position and ask the engine to generate a move from there.
won't the `play' command work? i often setup positions this way when debugging gnu go.
Yes, a number of black and white moves, including passes if the numbers of white and black stones differ would do the trick. Wouldn't it be simpler and cleaner to have commands to send lists of black and white stones?
Also, the current GTP spec on laodsgf is not explicit about this: are all setup nodes and properties allowed and taken into account when replaying the game record?
currently there seem to be no description of `loadsgf' in the latest specification draft, but i think that gtp shouldn't interfere with sgf. i mean, it shouldn't specify how to load an sgf file since sgf specification already describes that and i can see no point in changing its policy. i think that engines should load sgf files the same way, no matter asked by `loadsgf', through command line or by any other means.
This is what the October, 2002 (http://www.lysator.liu.se/~gunnar/gtp/gtp2-spec-draft2/gtp2-spec.html) says about loadsgf:
[...] "effects Board size and komi are set to the values given in the sgf file. Board configuration, number of captured stones, and move history are found by replaying the game record up to the position before move_number or until the end if omitted."
[...] "comments Due to the syntactical limitations of this protocol, the filename cannot include spaces, hash signs (#), or control characters. The command requires the controller and the engine to share file system, or at least that the controller has sufficient knowledge about the file system of the engine. If move_number is larger than the number of moves in the file, read until the end of the file. This command has no support for sgf files with variations or game collections."
My point is not about having GTP interfering with SGF, but a question about the handling of setup nodes in SGF files. I think that "replaying the game record" implies taking into account all setup nodes, and not just move nodes, but this could be interpreted differently. And if setup nodes should be used, then having explicit GTP commands to send lists of stones should not be big deal.
Marco Scheurer Sen:te, Lausanne, Switzerland http://www.sente.ch
-
Marco Scheurer -
Paul Pogonyshev