Re: [gnugo-devel] reading connections

[Daniel Bump]

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.

>>> 2) 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