[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: computer-go: Engineering (was: Most simple Go rules)
Yes, my protocol idea is definitey broken.
I guess it should be this (according to your email) if it's used:
--
When a player first passes, he either gives the arbiter his notion of
the score, or chooses not to use this protocol.
If the second player responds with a pass, he can do the same. If it
turns out both players reported a score to the arbiter and they agree,
the game is over and the agreed upon final score is official.
--
This is close to Mark Boon's idea which is also interesting, if I got
it right it goes like this:
If either player passes, the arbiter calculates a score and informs
both parties. If both parties agree, the game is over.
I think your protocol is slightly fairer because Marks is slightly
broken for the same reason mine is (but not nearly as broken as my
version.) In this case, if BOTH the arbiter and first passer is in
error, the second player could take advantage of it.
This might be more often that you might imagine, because I have seen
the same bug or misconception affect two different implementations of
something.
Is Marks version unfair if the arbiter is perfect? I think even then
it's unfair. If both the arbiter and first player agreed upon a score
that turns out to be correct, the second player, who is in denial may
learn he is doing better than he thought by just accepting this score.
Of course with Chinese scoring there is still no problem because if
the score is really correct, it will end up being official in either
case.
Don
Date: Wed, 27 Jun 2001 18:52:33 -0700
From: David Fotland <fotland@xxxxxxxxxxxxxxxxx>
At 02:52 PM 6/27/2001 -0400, you wrote:
>Your protocol has some appeal and suggests an OPTIONAL protocol
>similar to yours which would work fine for chinese style scoring: let
>a player pass with a score announcement and the next player can agree
>with this score and pass thereby ending the game. Or he can continue.
This is quite unfair to the first player that passes, since the second
player has the
option of accepting an incorrect score that is in his favor. To be fair,
each program would have
to announce a score to the arbiter, and be told if there is a disagreement,
but not which
score was higher.
David
>In either case this protocol is optional and no program is required to
>implement it.
>
>I was thinking about this discussion about protocols, implementations
>of games servers and such and here is what I have sorted out, I would
>like to hear some opinions:
>
> 1. If we want a better more modern protocol than gmp, go ahead and
> define it first. Make sure this is independant of any particular
> ruleset and supports them all.
>
> 2. Don't break existing protocols (like gmp) because it's silly to
> require programmers to reprogram unless there is something pretty
> valuable at stake.
>
> This can be accomplished by providing wrappers around gmp. If
> you invent a new protocol, you should make a gmp wrapper so
> that these program automatically work.
>
> Make the minimal implementation of the new protocol simple enough
> that it can be expressed fully by gmp.
>
> 3. After this, worry about how to write various utilities like GUI's
> for Go engines, game servers, autoplayers etc.
>
>
>Anyway, you have probably done a lot of work here, so I'm not
>suggesting that anything is broken, perhaps what you have here is what
>we need.
>
>But as long as you are trying for Japanese scoring, you are forced
>into some kind of very messy back and forth communication protocol
>that will be sure to cause lots of difficulty.
>
>Don
>
>
>
> As for the 100% accurate scoring, I think that depends on your point of
> view. It's trivial if you require all the dead stones to be captured
> off the
> board. In all other cases you'll always have problems scoring 'unfinished'
> games. I don't think a perfet solution exists for that. The solution I
> chose
> to implement for Go is the following: as soon as any of the player plays a
> pass, the server gives back to both players what the score is going to be
> (what are points, which stones are alive, dead, etc...). If both players
> agree with the score from the server, they continue to pass and the game
> ends. If either player does not agree with the given score (which I hope
> will only happen in a small percentage of the cases), he may continue to
> play. From then on, each time a player passes, the other players is
> given an
> extra prisoner. This is to compensate for the loss of territory caused to
> prove some stones are dead. We'll have to see how well this works in
> reality, but I believe it's the closest you can get to automate
> scoring. And
> I find it much more preferable over a system where the players have to
> indicate themselves which stones are dead at the end of the game.
>
> This last bit is more complicated for programs, since they'll have to look
> at the scoring from the server and start doing something about it when
> they
> disagree. But if you have a fully automatic way to match two programs,
> it's
> little bother to play all the way to the end anyway, you just have to
> wait a
> little longer. The beauty of the scheme is that it works the same for both
> Japanese and Chinese rules.
>
>
>
>
>
> From: "Mark Boon" <tesuji@xxxxxxxxxxxxxxxxx>
> Date: Wed, 27 Jun 2001 19:32:26 +0200
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
> Importance: Normal
> Sender: owner-computer-go@xxxxxxxxxxxxxxxxx
> Precedence: bulk
> Reply-To: computer-go@xxxxxxxxxxxxxxxxx
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Length: 5405
>
>
> > -----Original Message-----
> > From: owner-computer-go@xxxxxxxxxxxxxxxxx
> > [mailto:owner-computer-go@xxxxxxxxxxxxxxxxx]On Behalf Of Don Dailey
> > Sent: Wednesday, June 27, 2001 5:45 PM
> > To: computer-go@xxxxxxxxxxxxxxxxx
> > Cc: computer-go@xxxxxxxxxxxxxxxxx
> > Subject: Re: computer-go: Engineering (was: Most simple Go rules)
> >
> >
> >
> >
> > From: Christian Nentwich <c.nentwich@xxxxxxxxxxxxxxxxx>
> > Organization: University College London
> > Date: Wed, 27 Jun 2001 14:48:42 -0400
> > X-Mailer: KMail [version 1.2]
> > References: <000401c0fef6$f27afc10$093ba8c0@xxxxxxxxxxxxxxxxx>
> > MIME-Version: 1.0
> > Content-Transfer-Encoding: 8bit
> > Sender: owner-computer-go@xxxxxxxxxxxxxxxxx
> > Precedence: bulk
> > Reply-To: computer-go@xxxxxxxxxxxxxxxxx
> > Content-Type: text/plain; charset="iso-8859-1"
> > Content-Length: 1283
> >
> >
> > > I've never seen the GMP as a satisfactory solution. Wouldn't
> > it be much
> > > better to use a Go server as a tournament referee, having
> > all the programs
> > > communicate through TCP/IP? In straightforward cases, the
> > server can run on
> >
> > This has come up before. The answer is noone is willing to invest
> time.
> >
> > The truth is, the methods used by go servers on the internet
> > and GMP are
> > adhoc and horribly out of date. All of the problems discussed
> > here can be
> > addressed by proper software engineering. Martin Mueller
> > wrote a paper a
> > while ago in which he pointed out the benefits of rigorous software
> > engineering as Go programs become large.
> >
> > Interfaces to servers could be in a standard interface format
> > such as IDL or
> > even in XML. A simple middleware such as XMLRPC could be used for
> > communication (implementations exist for most programming
> > languages in use
> > today). Interfaces and a unit test server could be defined and
> > managed by a
> > group of individuals. Distribution would be hidden behind the
> > middleware and
> > you could run your competition in any way you like, connection
> > multiple
> > operating systems.
> >
> > The crucial point would be that a competent group of
> > individuals (of which
> > there seem to be many on this list), retains tight control of
> > interface
> > specification.
> >
> > Christian
> >
> >
> > I would consider helping if this was written to be totally platform
> > independent, and was capable of full game arbitration including
> > scoring the final outcome. It would have to be able to score the
> > final outcome accurately 100% of the time.
> >
> > Or is this illogical?
> >
> > The protocol should be trivial to implement in any language and not
> > require complicated supporting libraries, although these could be
> > provided for convienence.
> >
> >
> > Don
>
> At the moment I'm working with some friends on a solution to develop and
> deploy EJB enterprise software more easily and more cheaply. As a pilot
> project we made a game-server for several different kind of games,
> including
> Go of course.
>
> The game-server has been in an 'almost finished' state for over half a
> year
> now, since it's not very high priority for us. But we do have the
> intention
> to finish it this summer and allow people to use it to play all kinds of
> games on-line.
>
> The interface to the game-server is fairly straightforward and it can also
> be accessed through HTTP requests, so it's completely language
> independent.
> The problem is though that the XML that's passed to the HTTP requests (and
> back) is rather ad-hoc and should probably be replaced by something
> standardized. Still, it's much easier to access than servers like IGS. And
> in case you're using Java, I made an abstract class for
> computer-players to
> start games and play moves where you wouldn't need to write more than a a
> few dozen lines of code to hook into the server. Similar classes could be
> made for other languages.
>
> As for the 100% accurate scoring, I think that depends on your point of
> view. It's trivial if you require all the dead stones to be captured
> off the
> board. In all other cases you'll always have problems scoring 'unfinished'
> games. I don't think a perfet solution exists for that. The solution I
> chose
> to implement for Go is the following: as soon as any of the player plays a
> pass, the server gives back to both players what the score is going to be
> (what are points, which stones are alive, dead, etc...). If both players
> agree with the score from the server, they continue to pass and the game
> ends. If either player does not agree with the given score (which I hope
> will only happen in a small percentage of the cases), he may continue to
> play. From then on, each time a player passes, the other players is
> given an
> extra prisoner. This is to compensate for the loss of territory caused to
> prove some stones are dead. We'll have to see how well this works in
> reality, but I believe it's the closest you can get to automate
> scoring. And
> I find it much more preferable over a system where the players have to
> indicate themselves which stones are dead at the end of the game.
>
> This last bit is more complicated for programs, since they'll have to look
> at the scoring from the server and start doing something about it when
> they
> disagree. But if you have a fully automatic way to match two programs,
> it's
> little bother to play all the way to the end anyway, you just have to
> wait a
> little longer. The beauty of the scheme is that it works the same for both
> Japanese and Chinese rules.
>
> Mark
David Fotland