Re: [computer-go] java reference bot
On Fri, 2008-10-24 at 23:59 -0400, Michael Williams wrote: > I noticed that the Java reference bot does not listen to the color parameter > of genmove. It alternates colors regardless of what is specified. Yes, it's hacked together. I meant to come back to it later to clean up stuff like that. The GTP stuff is horrible anyway, I cut and pasted it from something on the web and then modified that. - Don > > Don Dailey wrote: > > On Mon, 2008-10-13 at 23:21 -0400, Joshua Shriver wrote: > >> Is the source available would be neat to see. > > > > Yes, get it here: http://cgos.boardspace.net/public/javabot.zip > > > > It includes a unix style simple Makefile. > > > > For you java programmers: I'm sure you won't like it - I'm not a java > > programmer but I did try to comment it fairly well and make it readable > > because it's supposed to be a reference bot. > > > > If anyone wants to clean it up, make it more readable, speed it up > > (without uglying it up) I would be interested and would incorporate that > > into the final reference bot.I don't know java specific do's and > > dont's and idioms for getting faster code. > > > > But of course first I want to find all the bugs. > > > > - Don > > > > > > > > > > > >> -Josh > >> > >> On Mon, Oct 13, 2008 at 7:14 PM, Don Dailey <[EMAIL PROTECTED]> wrote: > >> I made a reference bot and I want someone(s) to help me check > >> it out > >> with equivalent data from their own program. There are no > >> guarantees > >> that I have this correct of course. > >> > >> > >> > >> ___ > >> computer-go mailing list > >> computer-go@computer-go.org > >> http://www.computer-go.org/mailman/listinfo/computer-go/ > >> > >> > >> > >> ___ > >> computer-go mailing list > >> computer-go@computer-go.org > >> http://www.computer-go.org/mailman/listinfo/computer-go/ > > ___ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] java reference bot
I noticed that the Java reference bot does not listen to the color parameter of genmove. It alternates colors regardless of what is specified. Don Dailey wrote: On Mon, 2008-10-13 at 23:21 -0400, Joshua Shriver wrote: Is the source available would be neat to see. Yes, get it here: http://cgos.boardspace.net/public/javabot.zip It includes a unix style simple Makefile. For you java programmers: I'm sure you won't like it - I'm not a java programmer but I did try to comment it fairly well and make it readable because it's supposed to be a reference bot. If anyone wants to clean it up, make it more readable, speed it up (without uglying it up) I would be interested and would incorporate that into the final reference bot.I don't know java specific do's and dont's and idioms for getting faster code. But of course first I want to find all the bugs. - Don -Josh On Mon, Oct 13, 2008 at 7:14 PM, Don Dailey <[EMAIL PROTECTED]> wrote: I made a reference bot and I want someone(s) to help me check it out with equivalent data from their own program. There are no guarantees that I have this correct of course. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] java reference bot
Would you be willing to take what I have and integrate this for us? My currently "official" document is in the README file here: http://cgos.boardspace.net/public/javabot.zip (which has been slightly corrected, the Makefile didn't produce a valid jar file because the main class was not properly identified, but it compiles and works now.) I will eventually make a web page from this. - Don On Wed, 2008-10-15 at 06:57 +1300, Stuart A. Yeates wrote: > Seems like we need a short introduction too: > > "Go is a board game played on a rectangular grid, usually 19x19. > Pieces (or stones) are placed alternately by the black and white > players. Pieces are played onto empty vertexes with the aim of > surrounding and capturing the opponents pieces. The game continues > until both players pass. Go is scored on territory---essentially > whoever has the most territory wins. See > http://senseis.xmp.net/?BasicRulesOfGo for a more complete but > informal introduction. > > This task aims to solve the game of go using Monte Carlo simulation, > playing many random games to determine the best next move. For an > introduction to Monte Carlo simulation See > http://senseis.xmp.net/?MonteCarloTreeSearch or > http://en.wikipedia.org/wiki/Monte_Carlo_method > > This task uses a simple simulation and somewhat simplified > interpretation of the rules for the sake of ease of implementation." > > You also need to explain the following terms you use without > explanation: komi, play-outs, gtp, genmove, ko, superko. explanation > by reference to a good beginner page on http://senseis.xmp.net/ or > http://en.wikipedia.org/wiki/ should do > > cheers > stuart > > > > > > > On Tue, Oct 14, 2008 at 12:14 PM, Don Dailey <[EMAIL PROTECTED]> wrote: > > I made a reference bot and I want someone(s) to help me check it out > > with equivalent data from their own program. There are no guarantees > > that I have this correct of course. > > > > Doing 1 million play-outs from the opening position I get the following > > numbers for various komi: > > > > playouts:1,000,000 > > komi:5.5 > > moves: 111,030,705 > > score: 0.445677 > > > > playouts:1,000,000 > > komi:6.0 > > moves: 111,066,273 > > score: 0.446729 > > > > playouts:1,000,000 > > komi:6.5 > > moves: 111,040,546 > > score: 0.447138 > > > > playouts:1,000,000 > > komi:7.0 > > moves: 111,029,204 > > score: 0.4333795 > > > > playouts:1,000,000 > > komi:7.5 > > moves: 111,047,843 > > score: 0.421281 > > > > (I also get a score of 0.524478 for 0.0 komi) > > > > Score is from blacks point of view. Score is not the score of the > > best move of course but the combined average score of all 1 million > > play-outs using the stated komi and ranges from zero to one. > > > > I am going to build a test harness to compare multiple bots side by > > side using gtp commands. I made up two private gtp commands to > > facilitate this: > > > > ref-nodes -> return total moves executed in play-outs > > (including both pass moves at end of each > > play-out.) > > > > ref-score -> return total win fraction for black. > > > > NOTE: both commands report stats from last given genmove search. > > > > > > > > I hope to get peoples opinion on the following implementation > > specification. I'm definitely not a writer, so I need to know if this > > very informal spec is enough at least for experienced MC bot authors > > or where there are still some ambiguous points. > > > > > > I'm using the following implementation specification: > > > > [ bot implementation specification ] > > > > This is an informal implementation specification document for > > writing a simple Monte Carlo Bot program. The idea is to build a bot > > like this in ANY language and test it for performance (and > > conformity.) Can be used as a general language benchmark but is as much > > about the implementation as the language.This specification assumes > > some knowledge of go and Monte Carlo go programs. (If you don't like > > it, please write a better one for me!) > > > > > > > > 1. Must be able to play complete games for comprehensive conformity > > testing. > > > > 2. In the play-out phase, the moves must be chosen in a "uniformly > > random" way between legal moves that do not fill 1 point eyes and > > obey the simple-ko restriction. > > > > When a move in the play-out is not possible, a pass is given. > > > > 3. Play-outs stop after 2 consecutive pass moves, OR when N*N*3 > > moves have been completed, except that at least 1 move gets tried > > where N is the size of the board. So if the board is 9x9 then > > the game is stopped after 9*9*3 = 81*3 = 243 move assuming at > > least one move has been tried in the play-outs. > > > > 4. A 1 point eye is an empty point surrounded by friendly stones > > for the side t
Re: [computer-go] java reference bot
Seems like we need a short introduction too: "Go is a board game played on a rectangular grid, usually 19x19. Pieces (or stones) are placed alternately by the black and white players. Pieces are played onto empty vertexes with the aim of surrounding and capturing the opponents pieces. The game continues until both players pass. Go is scored on territory---essentially whoever has the most territory wins. See http://senseis.xmp.net/?BasicRulesOfGo for a more complete but informal introduction. This task aims to solve the game of go using Monte Carlo simulation, playing many random games to determine the best next move. For an introduction to Monte Carlo simulation See http://senseis.xmp.net/?MonteCarloTreeSearch or http://en.wikipedia.org/wiki/Monte_Carlo_method This task uses a simple simulation and somewhat simplified interpretation of the rules for the sake of ease of implementation." You also need to explain the following terms you use without explanation: komi, play-outs, gtp, genmove, ko, superko. explanation by reference to a good beginner page on http://senseis.xmp.net/ or http://en.wikipedia.org/wiki/ should do cheers stuart On Tue, Oct 14, 2008 at 12:14 PM, Don Dailey <[EMAIL PROTECTED]> wrote: > I made a reference bot and I want someone(s) to help me check it out > with equivalent data from their own program. There are no guarantees > that I have this correct of course. > > Doing 1 million play-outs from the opening position I get the following > numbers for various komi: > > playouts:1,000,000 > komi:5.5 > moves: 111,030,705 > score: 0.445677 > > playouts:1,000,000 > komi:6.0 > moves: 111,066,273 > score: 0.446729 > > playouts:1,000,000 > komi:6.5 > moves: 111,040,546 > score: 0.447138 > > playouts:1,000,000 > komi:7.0 > moves: 111,029,204 > score: 0.4333795 > > playouts:1,000,000 > komi:7.5 > moves: 111,047,843 > score: 0.421281 > > (I also get a score of 0.524478 for 0.0 komi) > > Score is from blacks point of view. Score is not the score of the > best move of course but the combined average score of all 1 million > play-outs using the stated komi and ranges from zero to one. > > I am going to build a test harness to compare multiple bots side by > side using gtp commands. I made up two private gtp commands to > facilitate this: > > ref-nodes -> return total moves executed in play-outs > (including both pass moves at end of each > play-out.) > > ref-score -> return total win fraction for black. > > NOTE: both commands report stats from last given genmove search. > > > > I hope to get peoples opinion on the following implementation > specification. I'm definitely not a writer, so I need to know if this > very informal spec is enough at least for experienced MC bot authors > or where there are still some ambiguous points. > > > I'm using the following implementation specification: > > [ bot implementation specification ] > > This is an informal implementation specification document for > writing a simple Monte Carlo Bot program. The idea is to build a bot > like this in ANY language and test it for performance (and > conformity.) Can be used as a general language benchmark but is as much > about the implementation as the language.This specification assumes > some knowledge of go and Monte Carlo go programs. (If you don't like > it, please write a better one for me!) > > > > 1. Must be able to play complete games for comprehensive conformity > testing. > > 2. In the play-out phase, the moves must be chosen in a "uniformly > random" way between legal moves that do not fill 1 point eyes and > obey the simple-ko restriction. > > When a move in the play-out is not possible, a pass is given. > > 3. Play-outs stop after 2 consecutive pass moves, OR when N*N*3 > moves have been completed, except that at least 1 move gets tried > where N is the size of the board. So if the board is 9x9 then > the game is stopped after 9*9*3 = 81*3 = 243 move assuming at > least one move has been tried in the play-outs. > > 4. A 1 point 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. Scoring is Chinese scoring. When a play-out completes, the > score is taken accounting for komi and statistics are kept. > > 6. Scoring for game play uses AMAF - all moves as first. In the > play-outs, statistics are taken on moves played during the > play-outs. Statistics are taken only on moves that are played by > the side to move, and only if the move in question is being > played for the first time in th
Re: [computer-go] java reference bot
Thanks for the comments and suggestions. My responses below ... On Tue, 2008-10-14 at 09:00 +0200, Denis fidaali wrote: > > Hi. > First things first : i think the specification is enougth as it is. > I hope that we can end up with something useable by anyone, > even non go people as a final goal. We'll have to get non-go experienced > people to beta-read it (and criticized) for us, i suppose. And we'll probably > have to get a HTML version with some fancy illustration (wich i won't be > helpfull for) I don't really want to be too involved in drafting this as it's not my forte. However I hope someone else (who is a better writer) will be willing. I recognize that my draft is far from ideal and I just hoped it was enough for those of us experienced to make sense of. Ultimately, I think we have to explain the rules and we could start with John Tromps logical rules contained at http://homepages.cwi.nl/~tromp/go.html and modify them accordingly or just integrate them into the document. Note that the only different between those rules and our rules is the suicide rule. > > I really look forward to be able to get involved non go people easily :) > I'm pretty sure a lot of them accepting this contest would end up > being very valuable for the community :) It's not clear to me whether others will respond, but it would be pretty cool and it would probably grow the computer go community at the same time. > > We'll probably have to get a bit deeper in the gtp-part ultimately. Do you mean the explanation or the actual commands I added? For the explanation we could point them to the excellent GTP draft standard and then explain this as 2 additional commands and then clarify what I wrong. I made only 2 GTP command as I wanted to be careful not to add anything that would likely impose a "barrier" to implementation and this influenced the specification in many places too. I would personally have made slightly different choices about some things which would have complicated the draft and the implementation. But I resisted doing that to keep it as generic as possible.Examples: my own test show that you should stop the AMAF tally a little early. Christopher Birk uses a decaying weight in his tally. I'm sure everyone who has implemented one of these has their own little "enhancement" but we want to keep this real simple. > -- > > === >5. Scoring is Chinese scoring. When a play-out completes, the > score is taken accounting for komi and statistics are kept. > > I think i would like it if we just gave how it should be done. > Using the eye definition we impose anyway. > > - > I propose : > - > 5. Scoring is done at the end of a game (two consecutive pass) >, in the following way : >each stone on the board gives a point to the player who >owns it. An empty intersection gives a point to the player (if any) who >has a stone on each orthogonal intersection around it. >If black's score is greater than 0.0 then it is scored as a black win. > Otherwise >it is scored as a white win. Yes, or as I mentioned we could borrow from the logical rules. > > === >1. Must be able to play complete games for comprehensive conformity > testing. > > I do not quite understand the point. But it can't really hurt either .. :) It seems slightly out of place but most of this is focused on how to do the play-outs and I wanted to make it clear that this should be able to play a real game and real games could be used for conformance testing (if you don't score very close to 50% against others, something is wrong.) > > === >2. In the play-out phase, the moves must be chosen in a "uniformly > random" way between legal moves that do not fill 1 point eyes and > obey the simple-ko restriction. > > When a move in the play-out is not possible, a pass is given. > > I'd like that we got more descriptive on the simple-ko restriction, if > possible. > (i'll try to propose something, but i'm getting low on time right now) Yes, this goes back to my point (and yours) that we really need to explain the rules. > > === > 3. Play-outs stop after 2 consecutive pass moves, OR when N*N*3 > moves have been completed, except that at least 1 move gets tried > where N is the size of the board. So if the board is 9x9 then > the game is stopped after 9*9*3 = 81*3 = 243 move assuming at > least one move has been tried in the play-outs. > > I don't quite get the point of the "except that at least 1 move gets tried" > part Because you don't want play-outs that stop before they begin. In order to get samples of moves you must play at least 1 move in the play-outs even if you are beyond move 243. > > === >ref-nodes -> return total moves executed in play-outs > (including both pass moves
Re: [computer-go] java reference bot
On Mon, 2008-10-13 at 23:21 -0400, Joshua Shriver wrote: > Is the source available would be neat to see. Yes, get it here: http://cgos.boardspace.net/public/javabot.zip It includes a unix style simple Makefile. For you java programmers: I'm sure you won't like it - I'm not a java programmer but I did try to comment it fairly well and make it readable because it's supposed to be a reference bot. If anyone wants to clean it up, make it more readable, speed it up (without uglying it up) I would be interested and would incorporate that into the final reference bot.I don't know java specific do's and dont's and idioms for getting faster code. But of course first I want to find all the bugs. - Don > > -Josh > > On Mon, Oct 13, 2008 at 7:14 PM, Don Dailey <[EMAIL PROTECTED]> wrote: > I made a reference bot and I want someone(s) to help me check > it out > with equivalent data from their own program. There are no > guarantees > that I have this correct of course. > > > > ___ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] java reference bot
Is the source available would be neat to see. -Josh On Mon, Oct 13, 2008 at 7:14 PM, Don Dailey <[EMAIL PROTECTED]> wrote: > I made a reference bot and I want someone(s) to help me check it out > with equivalent data from their own program. There are no guarantees > that I have this correct of course. > > ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] java reference bot
A minor correction in the GTP ref-score command. Score is not from blacks point of view, but from the point of view of the player who's turn to move it is. - Don On Mon, 2008-10-13 at 19:14 -0400, Don Dailey wrote: > I made a reference bot and I want someone(s) to help me check it out > with equivalent data from their own program. There are no guarantees > that I have this correct of course. > > Doing 1 million play-outs from the opening position I get the following > numbers for various komi: > > playouts:1,000,000 > komi:5.5 > moves: 111,030,705 > score: 0.445677 > > playouts:1,000,000 > komi:6.0 > moves: 111,066,273 > score: 0.446729 > > playouts:1,000,000 > komi:6.5 > moves: 111,040,546 > score: 0.447138 > > playouts:1,000,000 > komi:7.0 > moves: 111,029,204 > score: 0.4333795 > > playouts:1,000,000 > komi:7.5 > moves: 111,047,843 > score: 0.421281 > > (I also get a score of 0.524478 for 0.0 komi) > > Score is from blacks point of view. Score is not the score of the > best move of course but the combined average score of all 1 million > play-outs using the stated komi and ranges from zero to one. > > I am going to build a test harness to compare multiple bots side by > side using gtp commands. I made up two private gtp commands to > facilitate this: > >ref-nodes -> return total moves executed in play-outs > (including both pass moves at end of each >play-out.) > >ref-score -> return total win fraction for black. > > NOTE: both commands report stats from last given genmove search. > > > > I hope to get peoples opinion on the following implementation > specification. I'm definitely not a writer, so I need to know if this > very informal spec is enough at least for experienced MC bot authors > or where there are still some ambiguous points. > > > I'm using the following implementation specification: > > [ bot implementation specification ] > > This is an informal implementation specification document for > writing a simple Monte Carlo Bot program. The idea is to build a bot > like this in ANY language and test it for performance (and > conformity.) Can be used as a general language benchmark but is as much > about the implementation as the language.This specification assumes > some knowledge of go and Monte Carlo go programs. (If you don't like > it, please write a better one for me!) > > > > 1. Must be able to play complete games for comprehensive conformity > testing. > > 2. In the play-out phase, the moves must be chosen in a "uniformly > random" way between legal moves that do not fill 1 point eyes and > obey the simple-ko restriction. > > When a move in the play-out is not possible, a pass is given. > > 3. Play-outs stop after 2 consecutive pass moves, OR when N*N*3 > moves have been completed, except that at least 1 move gets tried > where N is the size of the board. So if the board is 9x9 then > the game is stopped after 9*9*3 = 81*3 = 243 move assuming at > least one move has been tried in the play-outs. > > 4. A 1 point 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. Scoring is Chinese scoring. When a play-out completes, the > score is taken accounting for komi and statistics are kept. > > 6. Scoring for game play uses AMAF - all moves as first. In the > play-outs, statistics are taken on moves played during the > play-outs. Statistics are taken only on moves that are played by > the side to move, and only if the move in question is being > played for the first time in the play-out (by either side.) A > win/loss record is kept for these moves. > > 7. The move with the highest statistical win rate is the one > selected for move in the actual game. In the case of moves with > even scores the choice is randomly made between them. > > 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 possible an optional > additional test which consists of long matches between other > known conforming bots. Your program should score close to 50% > against other "properly implemented" programs. > > 10. Suicide not allowed in the play-outs or in games it plays. > > 11. When selecting moves to play in the actual game (not play-outs) > positional superko is checked and
