Re: [computer-go] game-end Protocol

[Aloril <aloril@xxxxxx>]

On Tue, 2005-08-02 at 17:43, Nick Wedd wrote:
> 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.

Lets assume RudeTimeWasterBot program: It plays until there is no legal
move left for it except it leaves 2 single space empty eyes for each of
its groups. Lets also assume that this would be relatively strong, maybe
KGS 15k for example. In most cases I think this will mean more moves
than game + kgs-genmove_cleanup phase would mean. Also more of extra
moves would be harder to handle than with cleanup phase especially if
opponent likes to pass as much as possible. Should programs be able to
handle opponents like RudeTimeWasterBot?

If answer is yes, then I think time usage by cleanup phase should not be
problem. In my guess cleanup phase between well behaved programs will go
quite fast because position is getting more simple with each move. This
is not true with RudeTimeWasterBot vs "pass as much as possible":
position might stay complex for many moves.

>      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.

This will happen if other side implements cleanup and other side does
not implement it. Similar thing also happens if neither side implements
cleanup.

-- 
Aloril <aloril@xxxxxxxxxxxxxxxxx>
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/