[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [computer-go] GTP and Tourney in SmartGo 1.4
Your expessing only a point of view that is specific to your
circumstances, what works right now for you, what makes money since
it's how you make a living (which is fair), and not spending time
supporting other systems than your own which is also fair and your own
choice.
But there are others too. I'm trying to exress a view that I think is
better for the computer go community in general. Your support for the
computer go community is enormous because of interest generated by a
world class program, but I don't have that and neither do most of the
rest of us. You are in a position of strength because you don't need
anyone else, but a lot of hobbiest are interested.
I don't think GTP has anything to do with linux. GTP doesn't define
the communication channel, just the message structure.
I am actually mostly concerned about the platform. It's a windows
world and you're a windows guy, but my biggest fear is that
tournaments will start excluding windows. Since the strongest go
programs are windows based, my fear is that windows people will call
the shots and we will see other platforms excluded. My sense of the
computer go community is that the established programs and programmers
are kind of protective of their ways and not particularly interested
in the new-commers although there are exceptions. I didn't consider
you one of those.
I agree that it's silly to extend GMP. You must not have noticed my
sarcasm, I said it exactly for that reason. The point is that GMP
can't be considered a serious candidate for automated playing and yet
GTP, the only reasonable choice is being attacked as broken.
- Don
X-Original-To: computer-go@xxxxxxxxxxxxxxxxx
X-Sender: fotland%smart-games.com@xxxxxxxxxxxxxxxxx
Date: Fri, 12 Mar 2004 07:48:53 -0800
From: David Fotland <fotland@xxxxxxxxxxxxxxxxx>
Cc: computer-go@xxxxxxxxxxxxxxxxx
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-BeenThere: computer-go@xxxxxxxxxxxxxxxxx
X-Mailman-Version: 2.1.2
Precedence: list
Reply-To: computer-go <computer-go@xxxxxxxxxxxxxxxxx>
List-Id: computer-go <computer-go.computer-go.org>
List-Unsubscribe: <http://computer-go.org/mailman/listinfo/computer-go>,
<mailto:computer-go-request@xxxxxxxxxxxxxxxxx?subject=unsubscribe>
List-Archive: <http://computer-go.org/pipermail/computer-go>
List-Post: <mailto:computer-go@xxxxxxxxxxxxxxxxx>
List-Help: <mailto:computer-go-request@xxxxxxxxxxxxxxxxx?subject=help>
List-Subscribe: <http://computer-go.org/mailman/listinfo/computer-go>,
<mailto:computer-go-request@xxxxxxxxxxxxxxxxx?subject=subscribe>
Sender: computer-go-bounces@xxxxxxxxxxxxxxxxx
I haven't heard of anyone talking about patching up GMP. GMP was designed to
let programs communicate over 1200 baud unreliable modems, before the internet
was in general use. So it had to be binary, and it had to support retries,
with sequence
numbers, etc. It is silly to talk about extending it. It's used in
tournaments just due
to inertia, since so many programs implement some (usually compatible)
subset of it.
I don't think it will be quite so easy to integrate it into a windows
program with a GUI.
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.
I don't need GTP for tournaments, since it hasn't been required by one. If
a GTP tournament
requires me to provide a linux executable, I probably won't enter.
So why should I implement it? I think it would take more than an hour just
to find and read the spec :)
Regards,
David
At 10:26 AM 3/12/2004 -0500, Don Dailey wrote:
> > I am starting to feel like an old man who has been used to GTP for all
> > his life, got accustoned to its benefits and is just unable to
> > understand any of the reasons why the younger generation dislikes it...
>
>But it's the older generation that doesn't like it, because it's not
>the way they have always done it. It's the standard resistance to
>change even if beneficial. There is also the possibility that they
>might have to take an hour to actually implement it. That's how long
>it took me.
>
>Here is my experience with GTP:
>
>1. I implemented it based on the documentation for it in my weak Go
> program.
>
>2. I didn't have (or use) a reference implementation to compare
> against.
>
>3. I then designed a GTP autotester. I did nothing to try to prove
> that I had implemented GTP correctly. I only knew that it worked
> together with my own tools.
>
>4. William Shubert provided a java script that will interface a GTP
> speaking program to his server.
>
>5. I downloaded it, plugged my program in, and it WORKED the first
> time.
>
>This implies that it was easy to get it right, especially since I'm just
>an average programmer. But William Shubert must have got it right too,
>at least they work together easily.
>
>So I don't really understand ANY of these comments that imply GTP is
>screwed up. (It's not perfect, but what are you offering in place of
>it, GMP?)
>
>So I would view any criticism as flattery in this case. The ones
>criticizing GTP are not even trying to compare it against GMP in their
>posts.
>
>Is GTP ready for automated tournaments? There are certainly some
>rough edges, but what is the counter proposal, GMP???? Let's patch up
>GMP, "the well established standard" to do this since GTP stinks. Any
>volunteers? I didn't think so ...
>
>- Don
>
>
>
> On Fri, 12 Mar 2004, A van Kessel wrote:
>
> > > 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.
> >
> > This is a historic pain. We 'll have to deal with it.
> > I think the simplest way to handle \r is to just ignore
> > them.
>
> That is exactly what GTP does.
>
> > > 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.
> >
> > I fully agree. But: there is no other way.
> > Since the program's response is influenced
> > by it's internal (board)state, it is -in general-
> > not possible to think of the next GTP-command before
> > having read the first one's response.
> > a related topic is the implicit ordering of commands.
> > [ it would be a nice feature to inspect a program's internals,
> > while it is executing/processing a command. GTP won't let you]
>
> I am confused. First you say the controller should wait with issuing the
> next command until it got the answer of the previous one.
>
> > The sequencenumbers in the GTP request/respons lines serve
> > *no* purpose. They are just grep-beef.
>
> > not to play games. The absence of rules and timing
> > causes these to be handled in a program-specific way.
>
> What do you mean by "absence of timing"?
>
> > The timing is the wordt part: it causes too much
> > logic to be placed into the GTP controller ("driver")
> > program. This logic is program specific, and since
> > there is no "language" for expressing them (to the
> > other end of the connection) it is also tournament-
> > specific...
>
> Did you look at time_settings and time_left? What else should there be?
>
> Arend
>
> _______________________________________________
> computer-go mailing list
> computer-go@xxxxxxxxxxxxxxxxx
> http://computer-go.org/mailman/listinfo/computer-go
>
>_______________________________________________
>computer-go mailing list
>computer-go@xxxxxxxxxxxxxxxxx
>http://computer-go.org/mailman/listinfo/computer-go
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://computer-go.org/mailman/listinfo/computer-go
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://computer-go.org/mailman/listinfo/computer-go