Andrew wrote:
a) For consistency reasons, is it possible to rename showboard to show_board? There is already clear_board.
I guess it's possible but I think I prefer to stay with the GTP version 1 name here.
b) In section 6.2 Protocol Subsets, could we add subsection 6.2.3 Debug? That would be:
6.2.3 Debug The debug subset adds the commands: show_board
It doesn't seem very useful to formalize this as a protocol subset. The idea with these subsets is that an application should be able to say "requires the GTP tournament subset" to quickly declare what commands it needs. An application definitely shouldn't need a debug command in the first place.
c) In subsection 6.2.2 Regression, I would suggest the addition of: get_random_seed, set_random_seed Both commands are already implemented in GNU Go and I assume most, if not all engines would introduce a degree of randomness based on a seed. An engine that does not use pseudo-randomness (?) should output 1 for the get_random_seed command and save the parameter of the set_random_seed command in an otherwise unused variable, returning it if requested by the get_random_seed command.
I'm sceptical about this. First because I doubt that all engines use a scalar random seed like GNU Go does. Second because programs with a more sophisticated time handling than GNU Go probably has other, hard to control, sources of indeterminism.
Furthermore I'm not sure what purpose you see for these commands. Apparently you intend them for regression use but for reg_genmove it's advisable to turn off all random variations anyway, in order to avoid meaningless regression fluctuations.
d) For the showboard (or show_board) command, I would like to suggest the following description:
- show_board
arguments none effects none output the board in human-readable format. See Gnu Go output for example. fails board not cleared comments This command should fail if sent before the board is properly initialized (i.e. using the clear_board command).
I see no reason for this command to fail before clear_board has been invoked. Although the board configuration is unknown per the specification there is no reason for the engine to initialize it to something that's internally invalid. For your own sanity I'd recommend that you start up with an empty board. This is what GNU Go does, unless command line options tell it to load an sgf file before starting. My draft (not yet published) for the command looks like this:
* showboard arguments none effects none output board string*& board - A diagram of the board position. fails never comments The engine may draw the board as it likes. This command is only intended to help humans with debugging and the output should never need to be parsed by another program.
e) I had some doubts about whether Wallyplus should output the string "pass" or "resign" when it wants to pass. In the end, I implemented "pass", even though I was under the impression that the present spec is "resign". I would be grateful if this issue could be clarified (in the genmove command description).
Pass is correct. In section 3.2.1 a vertex entity is defined as a board coordinate or "pass", so I thought this would be clear. Of course I can add a comment in the command description if that will help. The purpose of "resign" is to give up the game.
f) Is there a command that tells GNU Go to **explain** why it generated a specific move?
No such command has been implemented. There is a command top_moves to list the top ten moves and their move values, but that's not the same thing.
Could such a command be included in the protocol?
Seems more appropriate for private extensions, I think.
I guess that last suggestion could be the matter of some debate, so I would like to explain why I am making it. Wallyplus can output a few lines of comments for every move it generates. I could save these comments in a string variable and just output them as a reply to the above command. It could prove quite useful to understand why an engine makes a particular move, without actually using a debugger while the engine is playing.
In GNU Go this kind of information is available as trace and debug messages (controlled by a couple of command line options), written to stderr.
/Gunnar