This thread started in the GNU Go list but I'm cc'ing the GTP list because the second part of this post is pertinent to the protocol. (The first part is more GNU Go specific.)
Trevor wrote:
The problem with this is that you must be very selective with what you generate sgf traces for. If you tried to do something like that for an entire genmove (for technical reasons you can't, but let's ignore that) of average complexity you would be completely drowned in variations and get a huge sgf file which would probably crash your sgf viewer or at least render it useless.
I would not want the tree generated for a genmove command, but rather, say, for an owl_attack or owl_defend. Perhaps an optional parameter with those commands requesting the SGF output?
This could be implemented fairly easily.
But do we really want it?
The sgf files generated by attack and defend --decide-worm can be enormous. For --decide-dragon we have an a priori bound of about 1000 nodes, so the file can still be big. Each node gets a comment, remember.
Once one has identified a reading or owl mistake one starts to tune, and the methodology is:
(1) Generate sgf file with variations;
(2) Examine file, try to fix something. Still broke? Go back to (1).
(3) Now that you've fixed it, run the regressions and see what else you broke.
If you add an owl defense pattern, you may have to add some attack patterns too.
For this process it is probably easier to generate the sgf file from the command line than from the gtp.
- Relatedly, how about enhancing loadsgf to accept the SGF file
directly on the GTP command line, like: loadsgf (;FF[4]GM[1]SZ[19]AP[Jago]AB[pd][dp][nq]AW[pp][dd])
This has been discussed before and I'm strongly against it. One reason is that we want to have external sgf files for the regressions because it allows them to be examined by other tools (sgf viewers) and other GNU Go modes. But most importantly I want to keep the GTP protocol simple and easy to inspect. Inline sgf would not be a development in the right direction.
This would avoid necessity for temp files, and would make a network based GTP easier to use.
The answer is to use native GTP commands to set up the position.
Right, I agree w/ you now. For example, use boardsize, white, and black GTP commands to set up a position.
I think there needs to be a way of transferring the board position over the GTP without resorting to (potentially) several hundred calls to black and white.
Currently in GNU Go the command worm_stones is a convenient way of transferring the board position from the engine to the controller. What about the other direction?
One possibility is to generalize black and white so that instead of a single stone they take a sequence of stones.
Dan