RE: [computer-go] Protocol B

["David Fotland" <fotland@xxxxxxxxxxxxxxx>]

My concern is time control.  If rounds have a maximum time, the best program
will play random moves very fast and never pass.  His opponents will always
lose on time.

David

> -----Original Message-----
> From: computer-go-bounces@xxxxxxxxxxxxxxxxx 
> [mailto:computer-go-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Mark Boon
> Sent: Wednesday, July 27, 2005 11:53 PM
> To: computer-go
> Subject: Re: [computer-go] Protocol B
> 
> 
> I've not really followed this discussion in full detail, but 
> what if the 
> score disagreement is in a seki?
> 
> David G Doshay wrote:
> 
> >
> > (pass - pass)
> > ?score?
> > if agree
> >     no problem, game over
> > if disagree
> >     resolve-disagreement-genmove
> >     if reply is pass
> >         resolve-disagreement-genmove
> >         if reply is pass
> >             game over, everyone alive
> >         if reply is not pass
> >             continue game with genmove
> >     if reply is not pass
> >         continue game with genmove
> 
> By the way: I'm in favour of playing out the game until the 
> very end. If 
> both agree on the score after the first two passes, fine, you 
> can stop 
> early. If there's a dispute (or if one side behaves like an ass) then 
> you should have a simple rule-set that leads to an 
> unambiguous end. That 
> means until all dead stones are captured, where for Japanese 
> type rules 
> (why use them in automatic tournaments anyway?) there's a one point 
> penalty for each pass. Game ends after the 3rd consecutive 
> pass (which 
> is not penalized).
> 
> All other protocols seem overcomplicated and will force one party or 
> another to put a lot of effort in resolving disputes. Playing 
> until the 
> end allows programs to put minimal effort into the 
> game-ending phase if 
> they wish. Those that complain saying: my program 'knows' 
> it's dead but 
> may make a mistake in capturing it will have to think again 
> about what 
> it is their program knows. If a program really 'knows' something is 
> dead, the algorithm to safely capture it is fairly trivial 
> and something 
> your program will need to be able to do anyway. Your program 
> will also 
> need to be able to capture a 'dead' group when in semeai, and that is 
> much more complicated. If your program can do that, it should also be 
> able to capture groups at the end. 
> _______________________________________________
> computer-go mailing list
> computer-go@xxxxxxxxxxxxxxxxx 
> http://www.computer-go.org/mailman/listinfo/computer-go/
> 


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