Re: computer-go: Most simple Go rules

[William Harold Newman <william.newman@xxxxxxxxxxx>]

On Wed, Jun 27, 2001 at 06:15:22PM -0500, Daniel Hallmark wrote:
> On 26 June 2001, Nick Wedd wrote:
> 
> > >What the organizers could do is take all the records of the games and run
> > >them through a program that checks for legality of all moves. This doesn't
> > >imply trusting the programers honesty and they don't have to be present and
> > >watch the game. Neither has the TD to do that nor anybody else.
> > 
> > Not all programs are capable of recording the game correctly.  Usually
> > one or other opponent manages it, but this can't be guaranteed.  Those
> > that do manage it don't always use a standard format.
> 
> 
> I haven't done any programming with the Go Modem Protocol, but assuming 
> the tournaments use a single standard protocol for communications, would 
> it not be possible to write an independent game-logging and move 
> validation application that could sit between the competitors and relay/
> snoop on all of their external communications.
> 
> Each side would submit their moves, etc. to the arbitor/logger which would 
> relay the move to the opponent and also create the official game log.  The
> arbiter could also perform hashing checks to notify the TD of ko violation,
> suicide violations, etc.  In short, you could have an automated watchdog to
> enforce the tournament rules rather than requiring constant human 
> supervision.
> 
> As long as the arbitor correctly implements the communications protocol 
> and accurately relays both player's output, I would think that the 
> logging/move-validation process could be made transparent to the two
> competitors.  The only thing I could see as a problem might be the small
> amount of extra time needed to perform the logging/checks, but this should
> impact each program equally so would not contribute to any game imbalance,
> and a small amount of additional time could be added to each game to 
> compensate if necessary.  
> 
> Naturally the source code to the logger as well as its output logs would 
> need to be available to all of the competitors.
> 
> Daniel Hallmark
> ... or would this be completely untenable for some reason I've overlooked?

I think it's just technical messiness mixed with some politics and
salesmanship issues, not any fundamental problem.

You could do it with serial cables, but then you'd need a lot of
serial ports on the arbiter machine/machines. And you'd need to write
the arbiter software.

You could do it with a LAN, but then you'd need to specify how the Go
Modem protocol stuff is sent over the LAN. That's not hard -- even
perhaps trivial for people using Unix-ish systems -- but it's still
one more thing for people to accept as a important enough to implement
and test and maintain. And according to a post from David Fotland some
time ago (months ago?), tournament participants and organizers are
more comfortable with serial cables than network connections. (And
you'd need to write the arbiter software.)

I myself (participant in one past tournament, and about to participate
in the tournament at the next AGA Congress) prefer network connections
in general: the hardware is a little nicer, and the software (like the
standard reliable portable TCP layer!) is much nicer (except perhaps
that people may not be enthusiastic about reconfiguring their laptops
to talk to the tournament's LAN setup). I also particularly like the
idea that if you do it with a LAN you can also put your arbiter on the
Internet before the tournament so that people can test for
compatibility problems before they come to the tournament.

If you're not committed to GMP, then once the new portable NNGS
implementation is more stable the problem might start to solve itself,
since it'll become easy to set up an NNGS server on a LAN at a
tournament. That might avoid some of the salesmanship issues, since
programmers seem reasonably motivated to implement the NNGS/IGS
protocol.

I'd guess that the most constructive things to do to help unscrew the
problem would be either (1) help straighten out the NNGS code, or (2)
work on documenting/standardizing either the complete protocol or a
subset sufficient for tournament play, or (3) make a clean reference
implementation of a subset of the NNGS/IGS protocol which suffices for
tournament play.

Implementing a GMP arbiter would also be constructive, but unless
someone's manufacturing a really cheap 16-port or 32-port serial board
(entirely possible..) it would probably be impractical to get it used
widely in tournaments. And even if the multiport board is easily
available, the code wouldn't see much use outside tournaments, so
maintaining the code would require a lot of technical attention; and
convincing tournament administrators that it was stable enough to
depend on would require a lot of salesmanship.

-- 
William Harold Newman <william.newman@xxxxxxxxxxxxxxxxx>
As usual, this being a 1.3.x release, I haven't even compiled this
kernel yet.  So if it works, you should be doubly impressed. 
  -- Linus Torvalds, announcing kernel 1.3.3 on the linux-kernel mailing list.
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C