I'm cross-posting this to the computer and gtp lists. Perhaps that is the best thing to do until the gtp list gets critical mass.
Heikki wrote:
I do agree that it is important to specify the behaviour of the undo command now, to avoid different implementations. But I also agree that the command is of limited use, probably only in human-computer games, which is but one use for the protocol. Thus I do not agree that "undo" must belong to the minimal set of commands all programs must implement.
Let me point out some possibilities that require undo.
An undo command opens up a world of possibilities. For example we could create a meta-machine that asks GNU Go for its top 2 or 3 moves, tries them, evalutes the board and then chooses the one with the top score. My guess is that it will be slow but immediately stronger than GNU Go. More ambitiously, make a metamachine that does limited global search. Slow, but computers don't get bored if the game is slow. One could code this in a couple of hours using perl and the gtp. But it would require undo. One could do experiments involving multiple engines along the lines of Althofer's n-Hirns. (I don't think the exact n-Hirn idea that was successful in Chess will work immediately in Go, though Althofer has been trying it, but there are possibilities of doing something using multiple engines.)
Dan
Dan wrote:
Let me point out some possibilities that require undo. [...] One could do experiments involving multiple engines along the lines of Althofer's n-Hirns. (I don't think the exact n-Hirn idea that was successful in Chess will work immediately in Go, though Althofer has been trying it, but there are possibilities of doing something using multiple engines.)
This can be implemented with undo, but a much better solution is to have a genmove command which doesn't imply that the engine automatically plays the move. This is how gg_genmove in GNU Go works and I have a feeling that maybe we should change the semantics of the genmove_white and genmove_black commands to get this behaviour. The drawback with this proposal is that in normal operation the driving program would have to echo the result from a genmove_black command in a black command to execute the move (and likewise for white moves).
While we're speaking of the genmove commands I also think that it may be better to replace the genmove_black and genmove_white commands with a single command genmove, taking "black" or "white" as parameter (this is also how gg_genmove is designed). I'm starting to think that this would be a better design. Similarly the black and white commands may be replaced by a single play command taking "black" or "white" as parameters together with the vertex to play.
Opinions?
/Gunnar
This can be implemented with undo, but a much better solution is to have a genmove command which doesn't imply that the engine automatically plays the move. This is how gg_genmove in GNU Go works and I have a feeling that maybe we should change the semantics of the genmove_white and genmove_black commands to get this behaviour. The drawback with this proposal is that in normal operation the driving program would have to echo the result from a genmove_black command in a black command to execute the move (and likewise for white moves).
I don't think that would work for some of the things I have in mind. I want to be able to generate positions a few moves down the move tree then go back to the original position.
No, this doesn't require anything extra in the protocol, only that the GUI keeps tracks of the moves that have been made. The "black" and "white" commands suffice to set up a position.
In order for the client to regenerate the position it has to choose an order to replace the stones on the board, and if there is a ko on the board it has to be careful that this order leaves the ko in the right state. Better just to have undo available.
I think undo is simple enough to implement that it is not a big imposition on programmers to make it part of the protocol. So I agree with Don.
Did you look at my undo patch? Does it seem OK?
Dan
Dan wrote:
In order for the client to regenerate the position it has to choose an order to replace the stones on the board, and if there is a ko on the board it has to be careful that this order leaves the ko in the right state. Better just to have undo available.
There is one natural order and that is to replay the moves in the same order as they have already been given, which happens to be equivalent to the proposed implementation of undo in GNU Go.
I think undo is simple enough to implement that it is not a big imposition on programmers to make it part of the protocol. So I agree with Don.
I would say that undo is a much more complex command than the rest of the commands in the discussed minimal set. I'd like to hear what authors of other programs think about the difficulties with implementing it for their programs.
Did you look at my undo patch? Does it seem OK?
It may be ok but it doesn't work well with handicap stones or loadsgf. My opinion is that the move stack should go into the board code in GNU Go.
Pierce wrote:
If you have a tournament where a human is part of the loop (perhaps a professional is playing all of the programs or something) then undo is a requirement. Humans make mistakes. SGF allows I, but go boards traditionally don't use I, stuff like that.
When I was speaking about tournament-kind of situations I meant exclusively computers vs computers. Anything involving a human I would categorize as GUI stuff, and there undo is indeed more important.
I even suspect without a human, communication problems, line noise, etc. would make undo a requirement.
GTP is assumed to work over an error-free channel. Line noise should be dealt with by lower-level protocols. The only important communication problem that can be anticipated is lost connections and then undo is not interesting but the ability of the driving program to set up the position from scratch.
For comparison it may be worth noticing that tournaments today are played through GMP and although that protocol does include an undo command I doubt it's used in practice in tournaments. I would even be surprised if more than a couple of programs have implemented it (through GMP that is, they may very well have undo through other channels).
Phil wrote:
The protocol should be case sensitive. If not, it would be impossible, for example to load SGF file ("loadsfg GAME1.sfg") on a Unix system since the Unix file systems are case sensitive.
Thanks. I had actually came to exactly the same conclusion earlier but couldn't recall why when I wrote this.
/Gunnar
Did you look at my undo patch? Does it seem OK?
It may be ok but it doesn't work well with handicap stones or loadsgf. My opinion is that the move stack should go into the board code in GNU Go.
What problem is there with handicap stones or loadsgf?
There is an initial position which is saved in starting_position. It is assumed that we do not want to take back moves before the starting position. So if you loadsgf you can't retract moves before the position that is loaded. The same is true with handicap stones. You can undo back to the point where the handicap is set up but not beyond it.
I didn't test the code after a load_sgf or fixed_handicap call so it's possible I missed something. Could you elaborate?
Did you look at my undo patch? Does it seem OK?
It may be ok but it doesn't work well with handicap stones or loadsgf. My opinion is that the move stack should go into the board code in GNU Go.
I didn't put it into board.c because there is already an undo that's implemented in play_ascii.c and play_gtp.c, which uses the sgf code. It seems that putting it into board.c would imply reimplementing these, which would actually cause problems for the sgf file that is being maintained at the same time.
In other words putting the undo into play_gtp.c but not board.c is a logical consequence of the decision that play_gmp.c and play_ascii.c will maintain an sgf tree but that play_gtp.c will not.
Dan