I found one specified issue that must be handled and requires an additional specification.
What to do to limit the length of the playout games? As was discussed in the last couple of days or so there are possible cases with multiple ko threats. Please not that the solution I am about to propose doesn't pretend to be a perfect solution since this is just a benchmark (like th eye rule, it isn't perfect) - but I think it does solve the problem. My idea is this: Allow up to N consecutive 1 point captures and then automatically terminate the game. So here is rule 13 in my list: 13. the play-outs terminate after the fifth consecutive 1 stone capture. If someone has a rationale for using a different number let's consider it. I picked 5 for no particular reason. And yes, I know that this might terminate games too early, but the only problem I want to solve is to prevent infinite games. There is of course an argument for using a much bigger number such as 10 or more - 5 single stone captures doesn't prove any kind of ko situation. But I prefer a very simple termination rule that is trivial to implement to something anal and complicated. I don't want to scare anybody away from building this benchmark. Would that guarantee no infinite games? Is there a reason to use a higher number than 5? Should we have an even simpler termination rule such as "no playout shall last more than BOARDSIZE * BOARDSIZE * 3 moves?" In addition I think it's good to require that integer komi be allowed. - Don On Sat, 2008-10-11 at 09:11 -0400, Don Dailey wrote: > 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/
