GTP version 2 has been a draft for nearly 3 years now, but it is becoming the de-facto standard for many programs. Still, maybe it is not too late to discuss some basic commands.
I never understood why version 2 introduced the clear_board command. What is the point of a separate boardsize command, if the engine's state is undefined after the command and you still have to send a clear_board? If the idea was to avoid a complete initialization of the Go engine, that is something the engine could easily do internally.
- Markus
Markus wrote:
I never understood why version 2 introduced the clear_board command. What is the point of a separate boardsize command, if the engine's state is undefined after the command and you still have to send a clear_board? If the idea was to avoid a complete initialization of the Go engine, that is something the engine could easily do internally.
The reason to introduce clear_board was that it seemed silly to be clearing the board as a side effect of setting the boardsize. It would have been an option to still require boardsize to also clear the board but I thought it made more sense to have those commands orthogonal. In part this is also a symmetry with not requiring the board to be empty at startup, which is useful when you can specify an initial position externally (in the case of GNU Go as a command line option).
/Gunnar
Gunnar Farnebäck wrote:
The reason to introduce clear_board was that it seemed silly to be clearing the board as a side effect of setting the boardsize. It would have been an option to still require boardsize to also clear the board but I thought it made more sense to have those commands orthogonal. In part this is also a symmetry with not requiring the board to be empty at startup, which is useful when you can specify an initial position externally (in the case of GNU Go as a command line option).
Only the only problem I see with this rationale is that I can't think of a situation where I would resize the board without clearing it. Resizing the board without clearing results in a board with an essentially meaningless piece arraignment. Is there really a useful case where you would resize the board but wish to save the positions that weren't truncated as a result of the resizing?
I agree that it's intuitive to have a clear_board command. However, not clearing the board after a resize seems unintuitive to me.
Sincerely, Chris Spencer
I think it makes sense the way it's currently implemented. What boardsize does to the board is undefined and I think it makes sense for it to remain undefined.
One might argue for a single board_size command that functions as both, and I would be alright with that but it shouldn't be called "boardsize". It should be something like reset_board with an argument indicating boardsize.
- Don
On Sunday 17 July 2005 4:24 pm, Chris Spencer wrote:
Gunnar Farnebäck wrote:
The reason to introduce clear_board was that it seemed silly to be clearing the board as a side effect of setting the boardsize. It would have been an option to still require boardsize to also clear the board but I thought it made more sense to have those commands orthogonal. In part this is also a symmetry with not requiring the board to be empty at startup, which is useful when you can specify an initial position externally (in the case of GNU Go as a command line option).
Only the only problem I see with this rationale is that I can't think of a situation where I would resize the board without clearing it. Resizing the board without clearing results in a board with an essentially meaningless piece arraignment. Is there really a useful case where you would resize the board but wish to save the positions that weren't truncated as a result of the resizing?
I agree that it's intuitive to have a clear_board command. However, not clearing the board after a resize seems unintuitive to me.
Sincerely, Chris Spencer
gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
drd@mit.edu wrote:
I think it makes sense the way it's currently implemented. What boardsize does to the board is undefined and I think it makes sense for it to remain undefined.
One might argue for a single board_size command that functions as both, and I would be alright with that but it shouldn't be called "boardsize". It should be something like reset_board with an argument indicating boardsize.
- Don
That doesn't really answer my question. Do you have a logical reason for why it "makes sense" to save piece positions? Have you ever played a game half way, resized the board, then kept playing without clearing the board?
If you have no need to save the pieces on the board, then you shouldn't. Not clearing the board just leads to confusion should you forget to explicitly tell the computer to resize AND clear, then it starts playing with a corrupted board.
Chris
What boardsize does to the board is undefined. You are adding content to something that was never stated. I don't think anyone ever said that boardsize was supposed to retain state from some other board. Undefined simply means that you shouldn't ASSUME the board is clear after a boardsize command.
So it makes perfect sense to me that the boardsize command isn't specifically designed to put the board into a specific state.
You will also note, to illustrate the point, that boardsize isn't designed to alter the playing level of the engine, or set handicap points. If it were overloaded to do other things like this, I would consider it confusing and ill defined.
Since what boardsize actually does is not defined as far as board contents are concerned, you are free to implement with an additional clearing of the board, which is what I do. It cannot be an error to do this because the standard explicity states that you can do anything you want. It's not wrong or even ugly to choose to clear the board, or not clear the board.
So I personally think the command set is fairly clean in this regard (although I have some other complaints I doubt anything would satisfy us all at the same time.)
boardsize is a specific command to change the size of the board and nothing else.
clear_board is a specific command to clear out the contents of the squares, and nothing else.
I like the idea of "reset_board 19" or similar to do what you want in a single command, but that's probably a different discussion.
Don
On Sunday 17 July 2005 8:54 pm, Chris Spencer wrote:
drd@mit.edu wrote:
I think it makes sense the way it's currently implemented. What boardsize does to the board is undefined and I think it makes sense for it to remain undefined.
One might argue for a single board_size command that functions as both, and I would be alright with that but it shouldn't be called "boardsize". It should be something like reset_board with an argument indicating boardsize.
- Don
That doesn't really answer my question. Do you have a logical reason for why it "makes sense" to save piece positions? Have you ever played a game half way, resized the board, then kept playing without clearing the board?
If you have no need to save the pieces on the board, then you shouldn't. Not clearing the board just leads to confusion should you forget to explicitly tell the computer to resize AND clear, then it starts playing with a corrupted board.
Chris
gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
drd@mit.edu wrote:
What boardsize does to the board is undefined. [snip]
And the point I've been trying to make is that this behavior should not be undefined. There's never a case where you would want to retain the board contents. Therefore, it makes sense to have boardsize explicitly clear the board contents.
Chris
I understand exactly what you are saying and why you feel uncomfortable with undefined behavior. I would expect that many would feel the same way you do and I don't make any claims that you are "wrong" or anything. It's a matter of personal preference.
What I'm defending is the consistancy of the current implementation or standard. I don't see anything unnatural or broken about it.
If you look at computer languages you may notice something similar in how arrays or variables get declared or initialized. Do they get set to zero when they are declared? If so, what is so special about zero? What actually happens depends on which language you program in and sometimes the scope of the variable. It seems to have something to do with the language designers philosophy or preference or perhaps hardware issues and convenience.
I personally don't have a problem with accepting that "boardsize n" isn't very useful unless it is immediately followed up with a clearboard command. In languages that don't initialize variables that are declared, I accept that the presence of a variable isn't very useful until it is assigned a value.
Again, if I had my choice a command would be added like "new_game n" or "reset_board n" and the other commands could be deprecated and their use discouraged. Personally, I find it slightly uncomfortable to use the terminolgy "boardsize" when you really mean "new_game."
I guess what really bothers me is that there is also a clear_board command. What should clear_board do if boardsize is mandated to also clear the board? It seems redundant.
So you would like boardsize to be defined to have the behavior that it clears the board too? Then it would be ok to forget to issue the clear_board command? I hope that's not the only reason for doing it. I really wouldn't like it to simply be a device to allow some sloppiness unless it was explicity designed to be the ONLY way to start a new game, in which case I would be comfortable with it being called something else to avoid confusion with previous versions of the protocol.
- Don
P.S. In my opinion, this is why you are uncomfortable:
boardize 13 clearboard play b e4 boardsize 13 genmove w
The last command is meaningless because you don't know what state the board is in. The second boardsize commmand left the board in an unknown state.
I'm not uncomfortable with this because I view it as simply an ill-formed set of commands. It's like a computer program that crashes because it is written wrong. You can't force a gtp controller to issue commands that make sense, it has to be built intelligently to do the right thing.
On Sunday 17 July 2005 10:50 pm, Chris Spencer wrote:
drd@mit.edu wrote:
What boardsize does to the board is undefined. [snip]
And the point I've been trying to make is that this behavior should not be undefined. There's never a case where you would want to retain the board contents. Therefore, it makes sense to have boardsize explicitly clear the board contents.
Chris
gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
I don't see much problem here, since it doesn't make things any harder for the engines, only a little for the controllers. As Gunnar pointed out, there are hardly cases when engines would like to make any specific setup after `boardsize', but the undefined state was left mainly for consistency with undefined state at startup.
In any case, I believe it is way to left to change anything for GTP 2 except for _clarifying_ things. Since the draft has been out there for so long, it has become a de facto GTP 2 standard. If Gunnar ever releases the final GTP 2, which he has promised for more than a year now, I believe, it should be 100% compatible with the draft.
If GTP 2 is released, then we can think about improvements for GTP 3.
One thing I'd like to see is expansion to Game Text Protocol, which already exists (virtually), but is not documented anywhere. There is at least one Game Text Protocol controller (Quarry) and at least two non-Go engines: GRhino (GTP Othello engine) and two or three engines from never released Inge Wallin's set of game engines for Amazons, Othello and Lines of Action.
Paul
On Monday 18 July 2005 10:51, Paul Pogonyshev wrote:
I don't see much problem here, since it doesn't make things any harder for the engines, only a little for the controllers. As Gunnar pointed
it does make it harder for the engine, you have to implement two commands. I always liked the simplicity of GTP and the low number of required commands, that is why I am a bit unhappy about this change in GTP 2.
In any case, I believe it is way to left to change anything for GTP 2 except for _clarifying_ things. Since the draft has been out there for so long, it has become a de facto GTP 2 standard. If Gunnar ever releases the final GTP 2, which he has promised for more than a year now, I believe, it should be 100% compatible with the draft.
I agree
- Markus
On Sunday 17 July 2005 18:54, Chris Spencer wrote:
Not clearing the board just leads to confusion should you forget to explicitly tell the computer to resize AND clear, then it starts playing with a corrupted board.
I agree. The boardsize parameter is a lot more essential than other parameters. While you can play a game ignoring the komi or time settings, you can hardly play without agreeing on the board size first.
Even if there was a rare occasion when a GTP controller program can do something meaningful without knowing the board size, this should be done with a private extension command, instead of putting the additional burden on all programmers to send and implement two commands.
The name 'boardsize' is a bit misleading, it should have been 'new_game', but that is not a big problem IMO.
I would propose to drop clear_board in GTP version 3 (or declare it deprecated or optional) and require boardsize to clear the board, like it was in version 1.
- Markus
-
Chris Spencer -
drd＠mit.edu -
Gunnar Farneb�ck -
Markus Enzenberger -
Paul Pogonyshev