[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: computer-go: Engineering (was: Most simple Go rules)
There are several reasons why I don't like the idea of passing the score to
the server. First of all, it would add complexity to the UI in order to be
able to send an estimate of the score. But more importantly, the server is
primarily meant to be used by people. And I think it's a bad idea to make
people send their estimate of the score. What level is a player who can give
the correct score at the end of the game more than 50% of the time? Well
into the dan-ranks I would guess. Only strong professionals sometimes say:
"Black wins by 1.5? Yes." and clear up the board without counting. This is
not for your average player.
Also, when there is a disagreement, all you need to do is to resolve the
area where you disagree with the referee. You don't need to play the game to
its bitter end just because something doesn't match.
It's a misunderstanding of you guys to think that the first person who
passes is at a disadvantage because he still gets the opportunity to play on
after his opponent passes as well. No-one will be forced to accept a score
he doesn't agree with. I know that two passes suffices with the Tromp/Taylor
rules, but I think forcing the game to be played to the end is cumbersome.
Any other mechanism will need more than two passes so that disagreements can
be resolved.
The main reason I came up with this scheme is because I wanted a way to
resolve the scoring as easily for humans as possible and have it still
compatible with traditional scoring methods. (I'm not 100% sure this is the
case, but someone will come up with a counter-example if there is one.) For
computers it's a different matter as they'll have no problem using the
Tromp/Taylor rules, or use the Chinese rules where they have to capture all
the dead stones.
Mark
> -----Original Message-----
> From: owner-computer-go@xxxxxxxxxxxxxxxxx
> [mailto:owner-computer-go@xxxxxxxxxxxxxxxxx]On Behalf Of Don Dailey
> Sent: Thursday, June 28, 2001 3:44 PM
> To: computer-go@xxxxxxxxxxxxxxxxx
> Cc: computer-go@xxxxxxxxxxxxxxxxx
> Subject: 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
>
>
>