Hello Gunnar,
Thanks for taking the time to answer my beginner's questions and sharing your experience. Here are some comments to your detailed reply:
On Friday 04 October 2002 23:46, Gunnar Farnebäck wrote:
Andrew wrote:
...
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.
I intend to write a nice KDE GTP 2 client, which everybody will be able to use to debug their own engines. In such a situation, I can clearly see that my application will want to say: "requires the standard GTP debug subset".
And IMHO an experimental Go engine definitely does need debug commands. Perhaps I am not making myself clear: this is not to debug programming errors, this is actually to debug/optimize/fine-tune the engine's algorithm.
So why not include such commands in the standard?
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.
I think I need more time to think about the (in)determinism issues. But yes, I agree that these commands do not make sense in the standard, due to the variety of ways a program can deal with randomness/determinism. Thanks.
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.
OK, but now I have another question: I have noticed that in response to the showboard command, GNU Go sends its output to stderr, not to stdout!!!
Wallyplus outputs the board to stdout.
I had earlier understood that the standard specified that the showboard command would cause the engine to output the board to stdout, in the normal response stream.
What is the correct behaviour?? Output to stderr or stdout?
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.
OK, thanks for the clarification.
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.
I guess again I refer to the case where I want a GUI client to communicate with the engine. It seems practical to have a standard command that will cause the engine to "explain" its last move.
When dealing with a new engine, I just would turn on this option in my GUI client and would get those explanations in a window; that would be very helpful to understand the logic of this new engine.
I have just finished rewiting AmiGo to play using GTP V2. Similarly to Wallyplus, I have called the new program Amigoplus. I have reused most of the front-end written for Wallyplus, and in fact I still have little understanding of the engine itself. So the debug commands would be useful in such a situation.
Again, I am very thankful to you and all that have worked on the GTP. It is a nice protocol to work with.
Regards,