Re: [computer-go] 2nd KGS Computer Go Tournament

[A van Kessel <adriaan.van.kessel@xxxxxxx>]

Personally, I can see no gain in forcing the
go playing programs (GPP's) to cooperate in
the scoring process.

1) There is no *need* to involve three (or more) programs
   into a process which can be performed by just one.
   IMO, the scoring process has been a source of conflicts
   on the servers, even for humans. No need to automate
   this process. 
   The tournament-organiser would have to wade through the
   logs afterwards, and not only understand the game,
   but also the protocol. (which was unnecessairy in the
   first place!)

2) GTP is not very well suited for tournament play.
   It was designed as a command set for controlling an
   engine, in order to perform GnuGo's regression tests.
   The protocol assumes the engine to maintain
   a minimum of state. (which could otherwise influence
   the outcome of the regression tests)
   The engine is supposed not to have notion of 'a game',
   it just supposed to do what it is told to do.

3) Adding two extra stages/phases to the game will
   be a problem for the simpler programs,
   or those that do keep state. These are forced to go into
   "play until dead stones removed" -mode from the beginning.
   NB: how would this mix with non-chinese rules ???

4) Too much (state,functionality) would be hidden in the
   KGS-GTP-bridge ('bot')

The simplest solution:
After two consecutive passes, the game has ended, as far
as the GPP's are concerned.
A third party (server,scoring-tool,administrator)
can than calculate the score. The GPP's don't even
have to know the result.

Regards,
AvK
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/