On Sat, 2008-10-11 at 09:13 -0700, David Fotland wrote: > If you don't have sueperko, I think you need a maximum moves stopping > criteria too.
Yes, I just thought of that myself before I even saw your email and I sent out an email addendum. Superko would of course solve the problem, but I'm trying to nail down, as much as reasonably possible, the most generic "defacto standard" that most of us are already using for the real simple bots. And from what I've read most people are not using PSK in their play-outs - at least not their light play-outs. Do you have some good ideas for move stopping criteria that we might consider? This is something that is not really standardized and I think each implementation is different so I want to find something really simple to implement. My idea is to either "stop after N 1 stone captures" or stop after N moves played where N is a function of the boardsize. - Don > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:computer-go- > > [EMAIL PROTECTED] On Behalf Of Don Dailey > > Sent: Saturday, October 11, 2008 6:11 AM > > To: computer-go > > Subject: [computer-go] simple MC reference bot and specification > > > > On Sat, 2008-10-11 at 13:33 +0100, Claus Reinke wrote: > > > I have a rough idea of what that might be. And I suspect that keeping > > > this "de facto standard" implicit has been hiding some actual > > > differences in what different people think that standard is. Some of > > > my questions arise from trying to pin down where and why different > > > authors have different ideas of what "the" > > > standard is. If there has been some explicit standardisation since > > > those papers were published, I'd be interested in a pointer to that > > > standard and its rationale. > > > > I'm going to publish a real simple java reference program and some docs > > to go with it and a program to "test" it for black box conformance. > > (Actually, it will test 2 or more and compare them.) I would like to > > get someone who writes better than I do to write up the standard in > > less casual language but it goes something like this: > > > > 1. A complete game playing program so it can also be tested in real > > games. > > > > 2. Play uniformly random moves except to 1 pt eyes and avoiding > > simple ko. When a move is otherwise not possible, pass. > > > > 3. Playout ends after 2 consecutive pass moves (1 for each side.) > > > > 4. 1 pt eye is an empty point surrounded by friendly stones for the > > side to move. Additionally, we have 2 cases. If the stone is NOT on > > any edge (where the corner is an edge) there must be no more than one > > diagonal enemy stone. If the point in question is on the edge, there > > must be NO diagonal enemy stones. > > > > 5. In the playouts, statistics are taken on moves played during the > > playouts. If the move is played FIRST (during the playout) by the > > side > > to move it is one data point and the win loss record is maintained. > > > > 6. The move with the highest statistical win rate is the one > > selected for move in the actual game. > > > > 7. In the case of moves with even scores a random selection is made. > > > > 8. Pass move are never selected as the final move to play unless no > > other non-eye filling move is possible. > > > > 9. Random number generator is unspecified - your program should > > simply pass the black box test and as a further optional test your > > program should score close to 50% against other "properly implemented" > > programs. > > > > 10. Suicide not allowed in the playouts or in games it plays. > > > > 11. When selecting moves to play in the actual game (not playouts) > > superko is checked and forbidden. > > > > 12. If a move has NO STATS taken (which is highly unlikely unless you > > do very few playouts) it is ignored for move selection. > > > > Did I miss anything? I would like to get feedback and agreement on > > this. > > > > Please note - a few GTP commands will be added in order to instrument > > any conforming programs. Haven't figured those out yet, but it will > > be designed so that it can report number of nodes, number of playouts, > > average score of playouts, etc. So the tester may set up some > > position > > and a ko, and ask for statistics based on the number of specified > > playouts. > > > > - Don > > > > > > > > > > > > > > > > >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
