[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: computer-go: Computer Go Tournament Program



Don wrote:

> I have    always agreed  on this  point,   but there  are   some minor
> advantages to such  a protocol if it  can be implemented  in a trivial
> and purely optional way.
> 
> But maybe it cannot.  As I think more about it, I see a problem that I
> hoped to avoid.  If  a program has pure  TT rules implemented, it must
> be modified   at least slightly  to accomodate  this special agreement
> protocol.  My hope was that a pure TT  program could remain completely
> unmodified, essentially ignoring the protocol  if it chooses to.   But
> this is not this case.

There's no need to modify pure TT programs. But there is a need for
incompatible programs to view games differently, as you noted.
In general, there will be three kinds of programs:

  (1) pure TT
  (2) agreement TT
  (3) optional agreement TT

of which the 3rd is most flexible, since it will have an option
whether or not to use agreement.

An arbiter can be written that uses 

  pure TT: between two type (1) programs or a type (1) and type (3) program
  agreement TT: between any 2 programs of types (2) or (3)

The only slightly problematic case is prog1 of type (1) vs prog2 of type (2)
Since agreement is impossible, the game will have to follow pure TT,
necessitating a special interface to prog2.
This interface can sit inbetween prog2 and the arbiter, and will make
prog2 look like type (1) to the arbiter.

What it does, is that when prog2 passes, the interface sends it back a
simulated opponent pass, and then relays prog2's next move
to the arbiter regardless of whether it's a pass.

This simple interface basically let's you turn any type (2) program into
a type (3) program.

You may consider this an ugly hack, but I think it's a neat solution worth
implementing just so people can better appreciate computer program's 'skills'.

regards,
-john