RE: computer-go: Interfacing 2 engines for automated play

["Fant, Chris" <chris.fant@xxxxxxxxxx>]

Dave said:

I think the comms overhead will be completely neglibable compared with the
work required to actually think of a move. Certainly that's the experience
with gnugo.

(Well, this will be true for any program that's strong enough to be worth
measuring : obviously a trivial go program can generate moves as fast
as it can think of random numbers)


I suspect that you could even get away with using sgf files as an
interface : each program starts from scratch, loads an sgf file, appends
its move to the file, then exits.


go modem protocol gives away nothing about the internals : it is simply
messages like "I play here" or "I pass" once the game parameters (handicap
etc) are negotiated.


Gnugo does have a separate text protocol which gives away a lot about
the internals. It's for regression testing, and allows driving program
to ask questions like "how would you attack the group at x" and
"how many liberties has group y"

Chris responds:

I know that modem play does not explicitly give away techniques of play.  But
over 100,000 automated games, a learning engine will notice certain weaknesses
in it's opponent.  That's what I was trying to say.