[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



David Fotland wrote:
> At 03:01 PM 3/12/2004 +0200, Paul Pogonyshev wrote:
> >A van Kessel wrote:
> > > > ... , but I consider the draft 2 of GTP
> > > > version 2 as the current version.
> > >
> > > IIRC gunnar backed out some "tournament" (sp?) commands,
> > > because there were too much fuzzy semantics involved, which
> > > he wanted to be settled out.
> > >
> > > IMO gtp is not ready for "automated" tournament use.
> > > too many things regarding starting up games, refereeing
> > > (communication with supervisor pgm) are not taken care of.
> > > This will effectively lead to "ad-hoc" modification of
> > > driver programs, operator intervention, or worse: program
> > > failure.
> >
> >I can see only one thing that is not taken care of: rule set
> >(chinese/japanese/whatever) as long as you speak about GTP 2.
> >Everything else: handicaps, komi, timing (Canadian overtime)
> >is implemented.  There is no support for say Japanese byo-yomi,
> >but I doubt any program supports it anyway and that it will be
> >used in tournaments, at least in the nearest future.
> >
> >In any case, information about rule set can be passed via
> >command line.  And even if it is not, difference between chinese
> >and japanese scoring is so insignificant that it hardly will
> >influence playing style of any engine.
> 
> 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.

I see your point.  I don't consider this "fair" and GNU Go doesn't
try such things, but well... rules doesn't forbid them.  In any
case, there is still command line.

> >About referee.  If it is another engine (beleived to score
> >correctly often enough), it can be communicated via GTP as
> >well.  If it is human, I wonder how you imagine communication
> >with him built into GTP?  In the latter case, reviewing of the
> >games is necessary anyway.
> >
> >And I suggest that you try and implement GTP 2 (required
> >commands plus tournament subset).  Then take a twogtp script
> >from GNU Go distribution (either Perl, Python or Pike one,
> >whichever you prefer) and play against GNU Go.  I'm sure
> >you'll have no problems.
> 
> What about those of use with Windows programs?  If there a referee that
> can talk to windows programs?

Maybe there's a misunderstanding.  By "referee" I meant a
third GTP engine that scores finished games if the players
are not capable of that.  At present, none of `twogtp' scripts
from GNU Go distribution has referee/arbiter support, but only
because no one requested that (and we obviously don't need it
for matches between different versions of GNU Go).  If there
are new weak engines that cannot score, authors can ask on GNU
Go mailing list and we will implement this so you can have GNU
Go or whatever else score your GTP matches.

And if you meant GTP controller for Windows, take one of the
scripts from GNU Go distribution.  Or take one of the Java
GUI programs that support GTP.

> 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?
> 
> My impression was that GTP was only for GNU/Unix/Linux, where everything
> is run from the command line.  This is not interesting for commercial 
> programs, since
> we all have pretty graphic interfaces and run under Windows.  Whether you 
> like Windows
> or not, its the only way to get sales.

Unless I miss something, there is still `stdin' and `stdout'.
People working on GNU Go who use Windows never complained about
twogtp scripts being unusable at least not on my memory.

As you may know, there is a large number of portable programs
(including scripting language; I beleive there are interpreters
for Perl and Python for Windows and Pike works too).  This
implies that there are pipes.  Maybe not the same pipes as ones
that exist in UNIX-like systems, but at least usable enough to
connect to `stdin' and `stdout'.

And if there are no pipes, I have to say that Windows is even
more screwed up than I thought.

Finally, GTP doesn't require using pipes.  All you need is a
controller that can connect via whatever your engine uses for
GTP communication.

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