[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