Re: [computer-go] GTP and Tourney in SmartGo 1.4

[Gunnar Farnebäck <gunnar@xxxxxxxxxxxxxx>]

Marco Sheurer wrote:
> I'd like our company to sponsor a Computer Go tournament for its 10th 
> anniversary (in fall 2004). It it happens it would be for GTP engines, 
> and would also be broadcasted on a server, possibly with a live video 
> stream, if anyone cares.

...and sparked a rather big and heated debate. Due to a temporary lack
of computer and internet at home after moving to Boston I wasn't able
to get into the discussion until now. In the following I'll comment
various messages from everywhere in the thread and will try not to be
too redundant.


Nick Wedd wrote:
> Insisting on GTP will exclude most competitors, as they don't support
> it.  I have heard that it is hard to implement, [...]

It's certainly possible to fail to follow the specification (the
badukiplus etc. programs come to mind) but I've never heard anybody
who has tried to do it saying that it was hard. On the contrary I've
heard many people saying that it's really easy, especially if they
have previously attempted to implement GMP.

> About five years ago, when many programs claimed to support GMP, the
> chance of two such programs actually being able to play an entire game
> by GMP was rather small.  If two of your entrants fail to get their game
> started, or play part of a game and then go to sleep, do you propose
> investigating which one is guilty of not doing the GTP stuff right, and
> giving the win to the other?

To begin with the natural setup is that a separate program, run by the
tournament organizers, acts as a controller. Thus the two engines (go
programs) would never speak directly to each other. In my opinion it
would be very natural to disqualify a program which fails to
communicate with the tournament software.

Should there ever be a serious disagreement about which party fails to
implement the GTP correctly I'll personally volunteer to determine who
doesn't follow the specification and show exactly where it goes
wrong. (Of course assuming that I either can test the programs myself
or get a complete log of the communication between the programs,
including sequence numbers.)


Anders Kierulf wrote:
> To really encourage the spread of GTP, is there any chance that license can
> be relaxed so that the copyright and permission notice only need to appear
> in source code, not in the running program, and not in the accompanying
> documentation?

This has been the intention all along. The license will either be
clarified or, if necessary, changed.


Mick Reiss wrote:
> Firstly there is the issue of DOS/Windows "translated mode" where \n gets 
> translated into \r\n pairs... I don't know if this will be happening in 
> this case, but I'd rather not have to worry about it at all.

The specification mandates \r to be ignored. This should work robustly
on all platforms except possibly on MacOS pre-X, which is more or less
obsolete anyway.

> Secondly, while you are writing the code you want to be able to easily 
> diagnose when you have made a mistake. -If you make a mistake in passing
> some incorrect combinations of end-of-line characters it is going to be 
> a pain to print out clear diagnostics.

We have not experienced any such difficulties for GNU Go.

> Another thing I don't like about GTP is the fact that the controller does 
> not have to wait for an answer before sending its next message. I see no 
> merit in this. It simply makes debugging harder.

As Arend commented this has been quite useful in the development and
testing of GNU Go. But please explain how it makes debugging harder
for you.


A van Kessel wrote:
> The sequencenumbers in the GTP request/respons lines serve
> *no* purpose. They are just grep-beef.

Nonsense. Those are needed in the GNU Go regression framework and have
been very valuable to help debugging both protocol and engine problems.

> Personally, I think GTP is not rich enough (yet) for
> computer go tournament use. It's primary use is to
> communicate with a program (while developing it) ,
> not to play games.

It's quite actively used for playing games on various servers, as well
as for local test series between different programs. Your opinion
seems rather unfounded.


Marco wrote:
> Last year the GIFU challenge (http://www.gifuit.com/igoe2003/) asked 
> entering programs to implement a new protocol, the SGMP (to the dismay 
> of the GTP fans). They included a way for entrants to test their 
> program before hand. Did it work? All the top programs were playing at 
> this tournament, so I suppose they complied and implemented the 
> required protocol. At least I haven't seen any complaints about this 
> requirement.

As has already been pointed out this wasn't a new protocol but rather
a restriction of GMP. Still it required more effort for the GNU Go
team to adjust the GMP implementation and test it than implementing
GTP from scratch would have done.

Also, at the end of the tournament they announced that this year they
would use an entirely new protocol called SBCP. I'm somewhat doubtful
this is going to happen, but if it does (and they again allow
participation through volunteer operators) GNU Go will handle this by
implementing an SBCP-GTP translator. Of course we'll provide this for
anybody else to use as well.


David Fotland wrote:
> Rules make a huge difference.  With Chinese rules there is no
> problem with trying horrible invasions at the end of the game if you
> are behind, looking for some bug in the opponent.  With Japanese
> rules, these moves will lose you a lot of points.  Go4++ used to do
> this.

Yes, the lack of commands to specify rules is a weakness in GTP
version 2. The main reason I decided to leave it out is that it's
unclear how to design this well to handle all the various
possible rule combinations. No doubt that will be a priority for a
later version 3 of the protocol.

For use in tournaments this is not a big deal though. Since the rules
are usually not changed during the tournament it's no big hurdle to
set them at startup time (whether through command line parameters,
GUI settings or compile time options).

> What about those of use with Windows programs?  If there a referee
> that can talk to windows programs?  Is there any standard for how to
> set up the Windows pipe involved (presumably some named pipe), since
> you can't do it form the command line like under Unix?

The natural way to communicate with a Windows program I assume is by
TCP/IP. At least it's my understanding that such connections are not
difficult to set up in that environment. In a tournament setting
TCP/IP would be natural for communication with Unix programs as well
since each program would want to run on their own computer. (Writing a
Unix program which interfaces a TCP/IP connection to an engine talking
GTP on stdin/stdout is trivial in an appropriate scripting language.)

> My impression was that GTP was only for GNU/Unix/Linux, where everything
> is run from the command line.

I'd like to understand how you've got this impression, so it can be
avoided in the future. GTP only specifies how to communicate over an
error-free channel. It does not require any particular channel or way
of starting the programs.

> I don't think it will be quite so easy to integrate it into a windows
> program with a GUI.

(Assuming this refers to GTP rather than GMP.)
That does of course depend on the design of the program, but
implementing GTP should definitely be no more difficult than
implementing GMP. Rather the opposite.

> I don't need GTP for testing, since I already have a test system
> that works well.  There is no point in rewriting it.  I'd rather
> work on the go engine.

Your call. For people with new programs or old programs without a good
testing framework it's an easy way to get one.

> I don't need GTP for tournaments, since it hasn't been required by
> one.

You never know what may happen in the future. I really doubt GMP will
hang on forever though.

> If a GTP tournament requires me to provide a linux executable,
> I probably won't enter.

As explained elsewhere GTP is not restricted to linux.

> So why should I implement it?

That depends on how interested you are in communicating with other
programs. For the moment you can get by with GMP and whatever you use
to play on IGS. The only current exception that I know of is that if
you want to play on KGS you can only do that using GTP.

For new programs I would say GTP is a lot more compelling, and well,
some day you might want to have an easy way to play Many Faces against
them. Conversely, whether you want the new programs to have an easy
way to play against Many Faces is of course up to you.

The possibility that future tournaments will require GTP is naturally
also a reason.

> I think it would take more than an hour just to find and read the
> spec :)

Well, at least I can reduce the time you need for finding it. It's at

http://www.lysator.liu.se/~gunnar/gtp

under the heading "New GTP Version 2 Specification Draft". Due to
popular demand I might even get around to removing "Draft" in the near
future.

> I worry that a GMP tournament would require Linux and run both
> programs on the same machine, connected by GTP over pipes.  I think
> that would be a step back :)

You can stop worrying about that. Such limitations (Linux, same
machine, pipes) are neither needed, nor desired.


Magnus Persson wrote:
> But my conclusion is that it is easy (if you know how to do it) to use
> GTP together with a program such as kgsGTP. But only with named pipes!

Except for the technicalities of getting pipes to work under Windows,
did you experience any other difficulties in implementing GTP in your
program? Is there any chance you can estimate how much time you needed
for the implementation, besides the pipe stuff?

/Gunnar
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://computer-go.org/mailman/listinfo/computer-go