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

[Don Dailey <drd@xxxxxxx>]

>  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