[computer-go] game-end Protocol

[Nick Wedd <nick@xxxxxxxxxxxxx>]

I have been reading the many postings on the game-end protocol.  I have 
a cold, and am feeling muzzy-headed, so I have not taken in much of it.
    In any case, I don't think I would have anything to say about the 
details of the protocol, I'll leave that to actual programmers.  All I 
am going to have to decide is about its application in KGS Computer Go 
events.

There are two things that worry me.  One, raised by David Fotland, is 
about time.
    All the KGS computer events that have been scheduled so far have 
tight time limits.  The time limits are absolute, so there is a precise 
upper bound for when games can end, and the next round is scheduled to 
start a few minutes after this.  If a resolution phase is added, and 
programs are allowed to think for significant time in it, then games 
will be able to overshoot the schedule.  In a human-scheduled tournament 
an overshoot is a nuisance - you just delay the start of the next round. 
In KGS tournaments, the scheduling is done by software, which cannot be 
persuaded to delay the next round.
    It is possible that I will set up a tournament with slow time 
limits, probably with some form of overtime, and one round to be played 
per day (I wonder if there is demand for this?).  For such a tournament, 
time spent on status resolution will not be a problem.  But for most KGS 
tournaments, I can't see how to manage it.

I will illustrate my other worry with an example.  Suppose the position, 
after both programs have passed, is like this:

 . . . # O . . . .      Chinese rules
 # # # # O . . # .      No komi
 . . . # O . O O .
 . . O # O . . . .
 # # # # O . . . .
 O O O # O . . . .
 O # O # O . . . .
 . # O # O . . . .
 # . O # O . . . .

Now the programs make assertions about the statuses of the strings on 
the board.  White (O) asserts that the two one-stone strings in the top 
half of the board are dead.  Black (#) asserts that that these two 
one-stone strings, and the seven-stone white string in the lower left, 
are dead.
    So play is resumed.  Black tries to kill the group in the lower 
left, and fails.  Then it picks off the odd white stone in the upper 
left.  White does not bother to pick off the odd black stone in the 
upper right (it does not realise that this is necessary, or its 
programmer has not managed the post-stop phase correctly).  Now the 
board looks like this

 . . . # O . . . .      Chinese rules
 # # # # O . . # .      No komi
 . . # # O . O O .
 . # . # O . . . .
 # # # # O . . . .
 O O O # O . . . .
 O . O # O . . . .
 . O O # O . . . .
 . O O # O . . . .

and Black claims to have won, as it has 18 stones on the board and 7 
points of territory = 25, while White has 20 stones on the board and 3 
points of territory = 23.
    I would not be happy to score this as a Black win.  At the game stop 
White was winning, and correctly stated the statuses of all strings.  I 
consider this should be good enough to win.

Here is what I am currently considering:
    Get genmove_cleanup working on the server, publicise it, and 
encourage its use.
    If, at the game stop, two programs agree on the score, then that's 
great, the result goes through automatically to the KGS tournament 
software.  Hopefully, this will be most games.
    If they disagree, they get sent a genmove_cleanup and resume play. 
Eventually they both pass again.  If the result now agrees with what the 
Tournament Organiser thinks it ought to be, the result goes through 
automatically to the KGS tournament software.  Hopefully, this will be 
most of the rest of the games.
    If however they generate a result which the Tournament Organiser 
thinks is wrong (like the above example), he will override the 
machine-generated result with what he considers is the correct one.
    If the programs are still trying to sort out the result when the 
next round is due, he will interrupt them and send in what he considers 
is the correct result.

Once we find that everything is working smoothly, all the programs have 
been programmed well, and the last two cases never happen for several 
consecutive tournaments, then we can remove the human intervention for 
subsequent ones.

Nick
--
Nick Wedd    nick@xxxxxxxxxxxxxxxxx
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/