Re: [computer-go] From zero to playing on CGOS in 10 minutes
I've gotten to a point where it probably makes sense to expose it to actual users. The location of the project is at http://plug-and-go.dev.java.net It's new, so I wouldn't be surprised if there are a few little bumps in the road still. But for anyone who'd like to start a bot, and who would consider writing one in Java, I believe it doesn't get any easier than this. There are plenty of instructions to get you on the way on the project pages. But I'm also sure they can always be improved, so I'd appreciate any suggestions anyone might have. Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
OK, after dicking about for a few hours with git and Mercurial I decided against using any of them. I keep getting errors or completely fail to understand how it works. It's just not intuitive enough to get going quickly. Moreover, if my goal is to get newcomers up and running quickly, I don't want to put them through the same pain. I'm quite comfortable with Subversion and I feel confident to get someone up to speed very quickly using Eclipse. I don't know how to do that with either git or Mercurial. It's probably possible. But not by me at this point in time. So I think I'm just going to use an online Subversion repository again. To avoid confusion I think it would be better not to use my existing project I have at dev.java.net. So I'll have to request a new project. On my own computer I've called it GoPluginFramework but I'm not sure if that's a good name. Basically what it does is allow someone to implement a relatively simple engine interface and have it act as a GTP program. For that you don't really need the whole project, only the JAR containing the Java application and drop your own JAR containing an engine implementation in the same directory. Then I have another project with a very simple random engine, which I called GoEngineTemplate. I expect this would be copied and then renamed by people wanting to start their own engine. And a third project has my reference bot. So I'm looking for suggestions. Suggestions for a project name(s) and suggestions how to best organize it. Should I put all three projects under the same online project, or create separate projects for them? Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
A post from Michael Williams led me to review this mail below once more. I hadn't looked at the code of Don's reference bot very closely until now and instead relied on the description he gave below: On 23-okt-08, at 14:29, Don Dailey wrote: Let me give you a simple example where we set the level to a measly 2 playouts: So you play 2 unformly random games that go like the following. This is a nonsense game that probably has illegal moves, but I just made up the moves for the sake of example: Black to move: c3 d4 g5 f6 b2 g7 c3 d4 g7 pass pass - black wins d4 b2 g7 c6 g5 a5 c3 d5 c7 pass pass - black loses In the first game black played: c3, g5, b2, c3, d4 ... but we cannot count d4 because white played it first. and we can only count c3 once because black played it twice. So our statistics so far for black is: c3 - 1 win 1 game g5 - 1 win 1 game b2 - 1 win 1 game In the second game black played: d4, g7, g5, c3, c7 - and black played these moves first but lost. If you combine the statistics you get: c3 1 win 2 games0.50 g5 1 win 2 games0.50 b2 1 win 1 game 1.00 d4 0 wins 1 game 0.00 g7 0 wins 1 game 0.00 c7 0 wins 1 game 0.00 The highest scoring move is b2 so that is what is played. It's called AMAF because we only care if black played the move, we don't care WHEN he played it. So AMAF cheats by viewing a single game as several separate games to get many data points from 1 game instead of just 1 data point. Please note that we don't care what WHITE did, we only take statistics on the moves black made (although we ignore any move that black didn't play first.) So if white plays e5 and later BLACK plays e5 (presumably after a capture) then we cannot count e5 because white played it first. I think if you study my example you will understand. So I understand from the above that when a playout leads to a win you add 1 to the wins. But in the code you subtract one when it leads to a loss. So doesn't the actual result statistics in the example above become: c3 1 win 2 games0.00 g5 1 win 2 games0.00 b2 1 win 1 game 1.00 d4 0 wins 1 game-1.00 g7 0 wins 1 game-1.00 c7 0 wins 1 game-1.00 Maybe it doesn't matter and it leads to the same result. But I was trying to make sense of what Michael wrote in light of what I coded myself. Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
Maybe Don built it that way so that the playouts could handle integer komi and the possibility of a draw. In that case, it would neither add one nor subtract one. Mark Boon wrote: A post from Michael Williams led me to review this mail below once more. I hadn't looked at the code of Don's reference bot very closely until now and instead relied on the description he gave below: On 23-okt-08, at 14:29, Don Dailey wrote: Let me give you a simple example where we set the level to a measly 2 playouts: So you play 2 unformly random games that go like the following. This is a nonsense game that probably has illegal moves, but I just made up the moves for the sake of example: Black to move: c3 d4 g5 f6 b2 g7 c3 d4 g7 pass pass - black wins d4 b2 g7 c6 g5 a5 c3 d5 c7 pass pass - black loses In the first game black played: c3, g5, b2, c3, d4 ... but we cannot count d4 because white played it first. and we can only count c3 once because black played it twice. So our statistics so far for black is: c3 - 1 win 1 game g5 - 1 win 1 game b2 - 1 win 1 game In the second game black played: d4, g7, g5, c3, c7 - and black played these moves first but lost. If you combine the statistics you get: c3 1 win 2 games0.50 g5 1 win 2 games0.50 b2 1 win 1 game 1.00 d4 0 wins 1 game 0.00 g7 0 wins 1 game 0.00 c7 0 wins 1 game 0.00 The highest scoring move is b2 so that is what is played. It's called AMAF because we only care if black played the move, we don't care WHEN he played it. So AMAF cheats by viewing a single game as several separate games to get many data points from 1 game instead of just 1 data point. Please note that we don't care what WHITE did, we only take statistics on the moves black made (although we ignore any move that black didn't play first.) So if white plays e5 and later BLACK plays e5 (presumably after a capture) then we cannot count e5 because white played it first. I think if you study my example you will understand. So I understand from the above that when a playout leads to a win you add 1 to the wins. But in the code you subtract one when it leads to a loss. So doesn't the actual result statistics in the example above become: c3 1 win 2 games0.00 g5 1 win 2 games0.00 b2 1 win 1 game1.00 d4 0 wins 1 game-1.00 g7 0 wins 1 game-1.00 c7 0 wins 1 game-1.00 Maybe it doesn't matter and it leads to the same result. But I was trying to make sense of what Michael wrote in light of what I coded myself. Mark ___ 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] From zero to playing on CGOS in 10 minutes
On Mon, 2008-10-27 at 17:19 -0200, Mark Boon wrote: So I understand from the above that when a playout leads to a win you add 1 to the wins. But in the code you subtract one when it leads to a loss. This is just semantics. In the literal code a win is 1 and a loss is -1 but when I actually report the statistics I fix this up to report a score between 0 and 1. I basically divide the final score by 2 and add 0.5 - Don 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] From zero to playing on CGOS in 10 minutes
If you ran 10,000 games your score is amazingly close - you won't be that close very often in 10,000 game samples. Of course I assume you are testing this against a fully conforming version. So what exactly are you doing here to save time? My understanding is that it has something to do with traversing the list in order to avoid extra random calls. So I assume you start with a shuffled list and go from there somehow? My program(s) keep up with empty points and selects only from them but I call the random number generator once for each legal move. - Don On Sun, 2008-10-26 at 20:24 -0200, Mark Boon wrote: On 25-okt-08, at 11:06, Don Dailey wrote: I would be interested to see if your biased version can pass my eventual conformance tests. If it can, more power to you, I might use the idea myself. I had it run 10,000 games over the weekend while away. The result is 49.9% (+/-0.5). I guess exactly 50% would be hard to come buy. Mark ___ 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] From zero to playing on CGOS in 10 minutes
One more observation, something I found curious, is that according to the statistics twogtp put together, the average game-length played was 119 moves. I also noticed this was the number after the other two runs I had of 1,000 games each. Since we made such a big deal about the average game-length being 111.05 I think this is curious. I believe this is a statistically significant deviation. But I must admit statistics is not a very strong point of mine. Any ideas how this could happen? Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
On Oct 26, 2008, at 7:19 PM, Mark Boon [EMAIL PROTECTED] wrote: One more observation, something I found curious, is that according to the statistics twogtp put together, the average game-length played was 119 moves. I also noticed this was the number after the other two runs I had of 1,000 games each. Since we made such a big deal about the average game-length being 111.05 I think this is curious. I believe this is a statistically significant deviation. But I must admit statistics is not a very strong point of mine. Any ideas how this could happen? 111 is for random games. What the bots actually do is far from random. I would be surprised if they did match. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
... the average game-length played was 119 moves. ... ... 111 is for random games. What the bots actually do is far from random. Or perhaps, if they can make a 9x9 game last 119 moves, it is not *that* far from random ;-). Darren ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
On Sun, 2008-10-26 at 21:10 -0200, Mark Boon wrote: When I look at CGOS right now my refbot TesujiRefBot has an ELO of 1286, JRef has 1290 and Cref has 1269. So evidence is mounting that my implementation, although completely different from yours, is conforming the definition you put together. Make sure you have the correct Jref and Cref - you want the one(s) with the highest version numbers (and those have played the most games too I believe.) - Don 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] From zero to playing on CGOS in 10 minutes
On Sun, 2008-10-26 at 21:19 -0200, Mark Boon wrote: One more observation, something I found curious, is that according to the statistics twogtp put together, the average game-length played was 119 moves. I also noticed this was the number after the other two runs I had of 1,000 games each. Since we made such a big deal about the average game-length being 111.05 I think this is curious. I believe this is a statistically significant deviation. But I must admit statistics is not a very strong point of mine. Any ideas how this could happen? I don't believe random games should be expected to have the same game lengths as (relatively) well played games. That's my guess. - Don Mark 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] From zero to playing on CGOS in 10 minutes
On Mon, 2008-10-27 at 08:51 +0900, Darren Cook wrote: ... the average game-length played was 119 moves. ... ... 111 is for random games. What the bots actually do is far from random. Or perhaps, if they can make a 9x9 game last 119 moves, it is not *that* far from random ;-). I know you were joking, but did you notice the trend? Random bots average 111 moves, bots that play over 2400 ELO stronger than that average 119 moves. So maybe you have to be STRONG to make the game last longer! However, I think I have a theory why the games go a few moves longer on average. My guess is that there are less 1 point eyes remaining with good play. Random play may create more eye points accidentally because neither opponent is actively trying to prevent this. - Don Darren ___ 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] From zero to playing on CGOS in 10 minutes
On 24-okt-08, at 21:19, Don Dailey wrote: \ I'm now running a twogtp test against your ref-bot. After 1,000 games my bot has a winning percentage of 48.8% (+/- 1.6) according to twogtp. That is well within 2 standard deviations so I don't think there is a problem. In fact it is within 1 standard deviation - you should get scores outside 1 SD fairly often, so this is actually quite good. I've run another 1,000 games. Now I get 49.2% (+/- 1.6) There's a small difference with the previous run, and that is that this time I used the move-selection process that has the bias in it towards moves next to illegal points. Apparently it doesn't have any noticeable effect on the outcome. Since it's more efficient by a good bit, and I hate to keep two versions of routines that do basically the same thing, I think I'm going to keep the one with the bias. This version is also running on CGOS now. It seems to be converging to the same ~1280 rating the other refbots have, although it probably didn't play a significant number of games yet. I'm running on a bit faster hardware than you do (2.8Ghz vs 2.67 Ghz.) but it does the benchmark in about 26 seconds in 64-bit mode, even with the suicide check in place. That's a good bit faster than your C version even. But I think you didn't spend much time, if any, optimizing for performance. After the weekend I'll make my stuff public, either through git or some other method. Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
I would be interested to see if your biased version can pass my eventual conformance tests. If it can, more power to you, I might use the idea myself. - Don On Sat, 2008-10-25 at 09:36 -0200, Mark Boon wrote: On 24-okt-08, at 21:19, Don Dailey wrote: \ I'm now running a twogtp test against your ref-bot. After 1,000 games my bot has a winning percentage of 48.8% (+/- 1.6) according to twogtp. That is well within 2 standard deviations so I don't think there is a problem. In fact it is within 1 standard deviation - you should get scores outside 1 SD fairly often, so this is actually quite good. I've run another 1,000 games. Now I get 49.2% (+/- 1.6) There's a small difference with the previous run, and that is that this time I used the move-selection process that has the bias in it towards moves next to illegal points. Apparently it doesn't have any noticeable effect on the outcome. Since it's more efficient by a good bit, and I hate to keep two versions of routines that do basically the same thing, I think I'm going to keep the one with the bias. This version is also running on CGOS now. It seems to be converging to the same ~1280 rating the other refbots have, although it probably didn't play a significant number of games yet. I'm running on a bit faster hardware than you do (2.8Ghz vs 2.67 Ghz.) but it does the benchmark in about 26 seconds in 64-bit mode, even with the suicide check in place. That's a good bit faster than your C version even. But I think you didn't spend much time, if any, optimizing for performance. After the weekend I'll make my stuff public, either through git or some other method. Mark 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] From zero to playing on CGOS in 10 minutes
Hi Don, I fixed another bug and now I get an average game-length of 111.05, which seems to be closer again to what you have. A million simulations now takes about 35 seconds. I'm now running a twogtp test against your ref-bot. After 1,000 games my bot has a winning percentage of 48.8% (+/- 1.6) according to twogtp. I suppose that's barely within the margin of error. I would have felt more confident if it had been closer. I'll run more tests over the weekend. And I'll put it up at CGOS as well. What are the number of playouts to use on CGOS? I believe the default of your ref- bot is 1,000, but on CGOS I see jref-XXX-2k and myCtest-2k-AMAF. So should I use 2,000 playouts? Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
Don, I have figured out the discrepancy in the average game length. As playout length I count from the start of the game, which gives me 114-115. I believe you count from the starting position where the playout starts. Because when I modify my code to do that I also get 111 moves per game on average. But I believe counting from the start is more meaningful if you're going to use the game-length as a reference number. Because otherwise you might get a different number depending on how explorative your search is. If your search tends to explore deeper lines in favour of wider lines you get a different number. Or at least you'll have to include the exploration-factor K in your UCT tree as a criteria. Mark On 22-okt-08, at 20:57, Don Dailey wrote: On Wed, 2008-10-22 at 20:29 -0200, Mark Boon wrote: On Wed, Oct 22, 2008 at 6:07 PM, Don Dailey [EMAIL PROTECTED] wrote: For one thing, komi is different. I used 0.5 for running this test. I would have use 0.0 but some implementations don't like even komi's. But the komi should have no effect on the playout length. I started out with 103 moves, but that was because of a mercy-rule. Without it it's 114. You have 111 rather consistently. And I assume you don't use a mercy-rule. Nor super-ko checking, is that correct? The score is what I was looking at, but you are right about the play-out length because the play-outs don't care what komi is. Do you use the 3X rule? Have you checked the other specs? My guess is that your playouts are not uniformly random - that is very easy to get wrong. Of course that is just a wild guess, it may very well be something completely different. - Don Another thing I have never looked at is AMAF. But that also shouldn't affect playout length I assume. By the way, thanks for all the pointers to 'git from everyone.' It's new to me and at first glance the specs look good, so I'll definitely give it a go. Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
On Thu, 2008-10-23 at 09:38 -0200, Mark Boon wrote: Don, I have figured out the discrepancy in the average game length. As playout length I count from the start of the game, which gives me 114-115. I believe you count from the starting position where the playout starts. Because when I modify my code to do that I also get 111 moves per game on average. But I believe counting from the start is more meaningful if you're going to use the game-length as a reference number. Because otherwise you might get a different number depending on how explorative your search is. If your search tends to explore deeper lines in favour of wider lines you get a different number. Or at least you'll have to include the exploration-factor K in your UCT tree as a criteria. I think you are misunderstanding how this works. I am defining a very simple non UCT bot and you are using terminology that implies something different that I am specifying. My timing is based solely on the opening position so how would it come out any different? We are both counting from the start of the game in this specific case. (I'll make sure my spec makes this unambiguous.) You also talk about how explorative your search is. The spec doesn't talk about a search or exploration, you just do 1 million uniformly random playouts from some specified position (the starting position.) The score should be the total black wins divided by the total number of games played and for this specific test it should be 0.5 komi.I will build a more sophisticated test soon that you simply run your bot against. The whole idea of this (for me) was to create the simplest reasonable go benchmark that played a reasonable game of go (depending on your definition of reasonable) so that hopefully many people might be willing to go to the trouble to implement it. I'm not going for a sophisticated UCT tree based algorithm, because that would require a considerably larger amount of effort for people to write, and it would also be significantly more difficult to define precisely. Having said that, you could easily take a UCT program and with very little effort have a simple mode that does what we are asking. The simple bot also serves as a stepping stone for beginners to start implementing their own more capable bot because they can be confident that they got the details correct and bug-free (more or less.) So you could grow a UCT program from this. - Don Mark On 22-okt-08, at 20:57, Don Dailey wrote: On Wed, 2008-10-22 at 20:29 -0200, Mark Boon wrote: On Wed, Oct 22, 2008 at 6:07 PM, Don Dailey [EMAIL PROTECTED] wrote: For one thing, komi is different. I used 0.5 for running this test. I would have use 0.0 but some implementations don't like even komi's. But the komi should have no effect on the playout length. I started out with 103 moves, but that was because of a mercy-rule. Without it it's 114. You have 111 rather consistently. And I assume you don't use a mercy-rule. Nor super-ko checking, is that correct? The score is what I was looking at, but you are right about the play-out length because the play-outs don't care what komi is. Do you use the 3X rule? Have you checked the other specs? My guess is that your playouts are not uniformly random - that is very easy to get wrong. Of course that is just a wild guess, it may very well be something completely different. - Don Another thing I have never looked at is AMAF. But that also shouldn't affect playout length I assume. By the way, thanks for all the pointers to 'git from everyone.' It's new to me and at first glance the specs look good, so I'll definitely give it a go. Mark ___ 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] From zero to playing on CGOS in 10 minutes
Don, You're probably right and I'm misunderstanding how it's supposed to work. Let me quote te original description: 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. Somehow I had constructed this to mean you're building a tree, where you only gather statistics when you enter a unique position. (Which is basically what would happen with UCT search expansion.) If this is not what it means I'm totally in the dark as to what exactly this section does mean. When you say you count all the playouts starting from an empty board, then I have no idea how our outcome can be different by 3-4 moves, which is coincidentally the average depth of a uniform tree of 1,000,000 moves on a 9x9 board. When I run the Orego playout benchmark(without mercy rule) for 1,000,000 playouts, I get an average game-length of 114.5. This is the same number I'm getting. With your explanation I think I'm getting a bit closer to understanding what your reference implementation does. But I'd like to see some more clarity before I'll attempt to implement it. Especially criteria #6 quoted above and #3 need some disambiguation (if that's a word). For example, in #3 I understand that the ending criteria is 2 consecutive passes or the game-length exceeds N*N*3 where N is the board-size. The bit about 'at least 1 move gets tried...' is not clear to me. I think it should read: Play-outs stop after 2 consecutive pass moves, OR when N*N*3 moves have been completed (where N is the size of the board). Except that at least 1 move gets tried. But that still leaves me the question how you can try at least one move when no legal moves are left? You may also need to include an exact defintion of AMAF. Mark On 23-okt-08, at 11:19, Don Dailey wrote: On Thu, 2008-10-23 at 09:38 -0200, Mark Boon wrote: Don, I have figured out the discrepancy in the average game length. As playout length I count from the start of the game, which gives me 114-115. I believe you count from the starting position where the playout starts. Because when I modify my code to do that I also get 111 moves per game on average. But I believe counting from the start is more meaningful if you're going to use the game-length as a reference number. Because otherwise you might get a different number depending on how explorative your search is. If your search tends to explore deeper lines in favour of wider lines you get a different number. Or at least you'll have to include the exploration-factor K in your UCT tree as a criteria. I think you are misunderstanding how this works. I am defining a very simple non UCT bot and you are using terminology that implies something different that I am specifying. My timing is based solely on the opening position so how would it come out any different? We are both counting from the start of the game in this specific case. (I'll make sure my spec makes this unambiguous.) You also talk about how explorative your search is. The spec doesn't talk about a search or exploration, you just do 1 million uniformly random playouts from some specified position (the starting position.) The score should be the total black wins divided by the total number of games played and for this specific test it should be 0.5 komi.I will build a more sophisticated test soon that you simply run your bot against. The whole idea of this (for me) was to create the simplest reasonable go benchmark that played a reasonable game of go (depending on your definition of reasonable) so that hopefully many people might be willing to go to the trouble to implement it. I'm not going for a sophisticated UCT tree based algorithm, because that would require a considerably larger amount of effort for people to write, and it would also be significantly more difficult to define precisely. Having said that, you could easily take a UCT program and with very little effort have a simple mode that does what we are asking. The simple bot also serves as a stepping stone for beginners to start implementing their own more capable bot because they can be confident that they got the details correct and bug-free (more or less.) So you could grow a UCT program from this. - Don Mark On 22-okt-08, at 20:57, Don Dailey wrote: On Wed, 2008-10-22 at 20:29 -0200, Mark Boon wrote: On Wed, Oct 22, 2008 at 6:07 PM, Don Dailey [EMAIL PROTECTED] wrote: For one thing, komi is different. I used 0.5 for running this test. I would have use 0.0 but some implementations don't like even komi's. But the komi should have no effect on the playout length. I started
Re: [computer-go] From zero to playing on CGOS in 10 minutes
On Thu, 2008-10-23 at 13:33 -0200, Mark Boon wrote: Don, You're probably right and I'm misunderstanding how it's supposed to work. Let me quote te original description: 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. Somehow I had constructed this to mean you're building a tree, where you only gather statistics when you enter a unique position. (Which is basically what would happen with UCT search expansion.) If this is not what it means I'm totally in the dark as to what exactly this section does mean. Let me give you a simple example where we set the level to a measly 2 playouts: So you play 2 unformly random games that go like the following. This is a nonsense game that probably has illegal moves, but I just made up the moves for the sake of example: Black to move: c3 d4 g5 f6 b2 g7 c3 d4 g7 pass pass - black wins d4 b2 g7 c6 g5 a5 c3 d5 c7 pass pass - black loses In the first game black played: c3, g5, b2, c3, d4 ... but we cannot count d4 because white played it first. and we can only count c3 once because black played it twice. So our statistics so far for black is: c3 - 1 win 1 game g5 - 1 win 1 game b2 - 1 win 1 game In the second game black played: d4, g7, g5, c3, c7 - and black played these moves first but lost. If you combine the statistics you get: c3 1 win 2 games0.50 g5 1 win 2 games0.50 b2 1 win 1 game 1.00 d4 0 wins 1 game 0.00 g7 0 wins 1 game 0.00 c7 0 wins 1 game 0.00 The highest scoring move is b2 so that is what is played. It's called AMAF because we only care if black played the move, we don't care WHEN he played it. So AMAF cheats by viewing a single game as several separate games to get many data points from 1 game instead of just 1 data point. Please note that we don't care what WHITE did, we only take statistics on the moves black made (although we ignore any move that black didn't play first.) So if white plays e5 and later BLACK plays e5 (presumably after a capture) then we cannot count e5 because white played it first. I think if you study my example you will understand. When you say you count all the playouts starting from an empty board, then I have no idea how our outcome can be different by 3-4 moves, which is coincidentally the average depth of a uniform tree of 1,000,000 moves on a 9x9 board. Well we are doing 2 completely different things - so it is surprising to me that we actually came that close. When I run the Orego playout benchmark(without mercy rule) for 1,000,000 playouts, I get an average game-length of 114.5. This is the same number I'm getting. You are probably doing what Orego does, not what my test specifies. I have to say I am surprised that you read all of that into my spec. I never once mentioned UCT, never gave a formula for UCT or anything of the such. How was it that you thought you were conforming without even agreeing on a UCT formula or whether the tree nodes are hashed or generated like a linked tree? With your explanation I think I'm getting a bit closer to understanding what your reference implementation does. But I'd like to see some more clarity before I'll attempt to implement it. Especially criteria #6 quoted above and #3 need some disambiguation (if that's a word). I think that's a word, I've seen it in the SAN chess document for Chess for how to disambiguate chess moves that have the same destination square and such. Anyway, I am not a good writer and had hoped that someone who is better would help me make it more clear. But at least I have a reference implementation with source code. When I get farther along and create a web page, I will include my example above or something like it if it isn't too confusing and try to improve it if nobody steps forward to help me. To me it seems perfectly clear and understandable, but since I wrote it there is no possible way to be objective about it. Of course I know that a non-go programmer or even a go programmer with no Monte Carlo Go experience would have fits with it so I appreciate that it can probably be greatly improved. I don't want it to be too stiff and formal, I want it to be easy for a casual hacker to understand. Of course I don't mind if someone creates a more formal description in addition to one that is easier to read. For example, in #3 I understand that the ending criteria is 2 consecutive passes or the game-length exceeds N*N*3 where N is the board-size. The bit about 'at least 1 move gets tried...' is not clear to me.
Re: [computer-go] From zero to playing on CGOS in 10 minutes
Thanks again for more explanations. I think the AMAF is clear to me now. When you say you count all the playouts starting from an empty board, then I have no idea how our outcome can be different by 3-4 moves, which is coincidentally the average depth of a uniform tree of 1,000,000 moves on a 9x9 board. Well we are doing 2 completely different things - so it is surprising to me that we actually came that close. This I don't understand. Both do a playout starting from an empty board, trying every move but ko-captures and eye-filling moves (using the same definition of eye). These are not completely different things. These should be EXACLTY the same things. The only thing different is that in my program the first few moves are selected by my UCT search instead of random selection as in your program. But I believe that does not affect the average game length one bit. When I just run playouts from an empty board I get the same average length, confirming that UCT selection does not influence the game- length. I didn't assume you were doing a UCT search. I didn't understand what kind of search you did exactly but in any case failed to see how it would change the average game-length. This is still something I don't understand. Are there others who implemented the same thing and got 111 moves per game on average? I tried to look through some posts on this list but didn't see any other numbers published. Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
On Thu, Oct 23, 2008 at 1:00 PM, Mark Boon [EMAIL PROTECTED] wrote: This is still something I don't understand. Are there others who implemented the same thing and got 111 moves per game on average? I tried to look through some posts on this list but didn't see any other numbers published. 111 matches my recollection from past experiments that I did with playouts that probably match Don's. I think that this number has been posted previously on the mailing list. Weston ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
Thanks again for more explanations. I think the AMAF is clear to me now. For what it is worth: I read the AMAF section as indicating that the bots are to play using AMAF heuristics - random playouts, followed by playing the AMAF-scored winning move, rinse and repeat. Which is why I thought I shouldn't try until I get round to making a performant, lightweight playout. Is that right, or are these bots supposed to play random playouts only, but provide scoring informaton as if those playouts were part of an AMAF bot? In either case, a working example explanation would make a useful addition. Btw, if there was a version of the bot specification on a wiki page, people might be able to clarify text or add questions. The wiki version could point to the current reference version (part of the reference implementation, I believe? I didn't want to look at Don's code until I get round to ripping out all the extra info and experimental code I keep playing with, which keeps my code from matching that 20k playouts/sec figure). This is still something I don't understand. Are there others who implemented the same thing and got 111 moves per game on average? I tried to look through some posts on this list but didn't see any other numbers published. I'm not yet implementing the reference spec, but if you're just asking about random playouts: yes, I tend to get around 111 moves. The most frequent game length is even shorter (81 positions+ ~39 positions freed by capture - ~13 positions occupied by eyes = ~107 moves), but there are more longer games than shorter ones (see histogram below). Claus $ ./Go.exe 0.5 1 Size: 9 Komi: 0.5 Games: 1 (1.3056 average black-white score difference) Black: 5141 games (26.9716=6.6633+20.3083 average score) White: 4859 games (25.1660=6.1724+18.9936+0.5 average score) Draws: 0 Gobble-style eye: 442830 capture (w/o ko): 986684 ko candidate: 87978 positional superko: 34 suicide: 595044 game lengths (average: 111.1783): [(80,3),(81,9),(82,9),(83,19),(84,16),(85,47),(86,44),(87,57),(88, 79),(89,82),(90,124),(91,156),(92,158),(93,159),(94,223),(95,234),(96,236),(97,312),(98,278),(99,310 ),(100,282),(101,301),(102,305),(103,340),(104,282),(105,308),(106,311),(107,255),(108,300),(109,291 ),(110,252),(111,253),(112,246),(113,241),(114,195),(115,199),(116,200),(117,167),(118,134),(119,144 ),(120,130),(121,101),(122,88),(123,76),(124,79),(125,67),(126,74),(127,61),(128,58),(129,66),(130,5 5),(131,92),(132,44),(133,87),(134,70),(135,101),(136,79),(137,110),(138,93),(139,110),(140,73),(141 ,81),(142,65),(143,98),(144,61),(145,60),(146,58),(147,60),(148,30),(149,30),(150,29),(151,22),(152, 23),(153,16),(154,18),(155,14),(156,14),(157,13),(158,11),(159,3),(160,6),(161,3),(162,1),(163,6),(1 66,2),(184,1)] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
On Thu, 2008-10-23 at 15:00 -0200, Mark Boon wrote: Thanks again for more explanations. I think the AMAF is clear to me now. When you say you count all the playouts starting from an empty board, then I have no idea how our outcome can be different by 3-4 moves, which is coincidentally the average depth of a uniform tree of 1,000,000 moves on a 9x9 board. Well we are doing 2 completely different things - so it is surprising to me that we actually came that close. This I don't understand. Both do a playout starting from an empty board, trying every move but ko-captures and eye-filling moves (using the same definition of eye). These are not completely different things. These should be EXACLTY the same things. The only thing different is that in my program the first few moves are selected by my UCT search instead of random selection as in your program. But I believe that does not affect the average game length one bit. I believe this might have a small effect on the game length, but it's probably not the explanation. When I just run playouts from an empty board I get the same average length, confirming that UCT selection does not influence the game- length. I didn't assume you were doing a UCT search. I didn't understand what kind of search you did exactly but in any case failed to see how it would change the average game-length. You are getting about 3.5 extra moves. I count pass moves including the 2 at the end, and I assume you do the same but if you were not that would bring your count down - so that doesn't explain the problem. This is exactly why I wanted to do this - to get verification between bots. So we must explore these 2 possibilities: 1. I am doing it wrong. 2. You are doing it wrong. The things to check for both of us are: 1. proper 1 point eye definition? 2. simple ko testing (are you testing for simple ko?) 3. proper node count accounting. 4. properly random (in a perfectly uniform way.) 5. N*3 max game length (this is probably not the issue even if it's wrong) 6. Do we stop after 2 passes? 7. Never include a pass move in playout UNLESS no other move is possible. 8. suicide NOT allowed. 9. PSK never tested in the playouts. This is still something I don't understand. Are there others who implemented the same thing and got 111 moves per game on average? I tried to look through some posts on this list but didn't see any other numbers published. So far I don't think anyone else has published. Please go down my checklist above and I'll do the same. If I implemented it wrong, I did it in all 3 bots I have completed so far, but that means little, they were all almost direct ports of each other in C-like languages. - Don Mark 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] From zero to playing on CGOS in 10 minutes
Just to be clear, the average length of the playout is what we are looking for, not the average length of games that might be played from genmove commands. - Don On Thu, 2008-10-23 at 15:00 -0200, Mark Boon wrote: Thanks again for more explanations. I think the AMAF is clear to me now. When you say you count all the playouts starting from an empty board, then I have no idea how our outcome can be different by 3-4 moves, which is coincidentally the average depth of a uniform tree of 1,000,000 moves on a 9x9 board. Well we are doing 2 completely different things - so it is surprising to me that we actually came that close. This I don't understand. Both do a playout starting from an empty board, trying every move but ko-captures and eye-filling moves (using the same definition of eye). These are not completely different things. These should be EXACLTY the same things. The only thing different is that in my program the first few moves are selected by my UCT search instead of random selection as in your program. But I believe that does not affect the average game length one bit. When I just run playouts from an empty board I get the same average length, confirming that UCT selection does not influence the game- length. I didn't assume you were doing a UCT search. I didn't understand what kind of search you did exactly but in any case failed to see how it would change the average game-length. This is still something I don't understand. Are there others who implemented the same thing and got 111 moves per game on average? I tried to look through some posts on this list but didn't see any other numbers published. Mark ___ 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] From zero to playing on CGOS in 10 minutes
On Thu, 2008-10-23 at 18:46 +0100, Claus Reinke wrote: Thanks again for more explanations. I think the AMAF is clear to me now. For what it is worth: I read the AMAF section as indicating that the bots are to play using AMAF heuristics - random playouts, followed by playing the AMAF-scored winning move, rinse and repeat. Which is why I thought I shouldn't try until I get round to making a performant, lightweight playout. Is that right, or are these bots supposed to play random playouts only, but provide scoring informaton as if those playouts were part of an AMAF bot? I'm not sure I understand the question. You are implementing a bot which can play real games on CGOS for instance. It will generate and play a move from the gtp genmove command based on AMAF scoring of N random playouts. Of course if you want to compare statistics, you don't have to have a full game playing bot, you can just see if random playouts match what we are getting. But when I build a more sophisticated conformance tester it will require a full game playing bot. When I ask for scoring information using ref-score I simply want to know the fraction of times that the color who is to move won those playouts. That will depend of course on how komi is set. Did that answer your question? - Don In either case, a working example explanation would make a useful addition. Btw, if there was a version of the bot specification on a wiki page, people might be able to clarify text or add questions. The wiki version could point to the current reference version (part of the reference implementation, I believe? I didn't want to look at Don's code until I get round to ripping out all the extra info and experimental code I keep playing with, which keeps my code from matching that 20k playouts/sec figure). This is still something I don't understand. Are there others who implemented the same thing and got 111 moves per game on average? I tried to look through some posts on this list but didn't see any other numbers published. I'm not yet implementing the reference spec, but if you're just asking about random playouts: yes, I tend to get around 111 moves. The most frequent game length is even shorter (81 positions+ ~39 positions freed by capture - ~13 positions occupied by eyes = ~107 moves), but there are more longer games than shorter ones (see histogram below). Claus $ ./Go.exe 0.5 1 Size: 9 Komi: 0.5 Games: 1 (1.3056 average black-white score difference) Black: 5141 games (26.9716=6.6633+20.3083 average score) White: 4859 games (25.1660=6.1724+18.9936+0.5 average score) Draws: 0 Gobble-style eye: 442830 capture (w/o ko): 986684 ko candidate: 87978 positional superko: 34 suicide: 595044 game lengths (average: 111.1783): [(80,3),(81,9),(82,9),(83,19),(84,16),(85,47),(86,44),(87,57),(88, 79),(89,82),(90,124),(91,156),(92,158),(93,159),(94,223),(95,234),(96,236),(97,312),(98,278),(99,310 ),(100,282),(101,301),(102,305),(103,340),(104,282),(105,308),(106,311),(107,255),(108,300),(109,291 ),(110,252),(111,253),(112,246),(113,241),(114,195),(115,199),(116,200),(117,167),(118,134),(119,144 ),(120,130),(121,101),(122,88),(123,76),(124,79),(125,67),(126,74),(127,61),(128,58),(129,66),(130,5 5),(131,92),(132,44),(133,87),(134,70),(135,101),(136,79),(137,110),(138,93),(139,110),(140,73),(141 ,81),(142,65),(143,98),(144,61),(145,60),(146,58),(147,60),(148,30),(149,30),(150,29),(151,22),(152, 23),(153,16),(154,18),(155,14),(156,14),(157,13),(158,11),(159,3),(160,6),(161,3),(162,1),(163,6),(1 66,2),(184,1)] ___ 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] From zero to playing on CGOS in 10 minutes
OK, if the following is not the reason, then I don't know anything anymore :) My playouts allow multiple suicide. I believe Orego does the same. I found that not checking for that actually made things faster overall. But I bet that accounts for the longer average game-length. If suicide is not allowed I'd say that criteria #2: 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. should explicitly make mention of suicide not being allowed. Mark On 23-okt-08, at 15:32, Weston Markham wrote: On Thu, Oct 23, 2008 at 1:00 PM, Mark Boon [EMAIL PROTECTED] wrote: This is still something I don't understand. Are there others who implemented the same thing and got 111 moves per game on average? I tried to look through some posts on this list but didn't see any other numbers published. 111 matches my recollection from past experiments that I did with playouts that probably match Don's. I think that this number has been posted previously on the mailing list. Weston ___ 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] From zero to playing on CGOS in 10 minutes
On Thu, 2008-10-23 at 16:04 -0200, Mark Boon wrote: OK, if the following is not the reason, then I don't know anything anymore :) My playouts allow multiple suicide. I believe Orego does the same. I found that not checking for that actually made things faster overall. But I bet that accounts for the longer average game-length. You playouts allow multiple suicide. I assume you do not allow single stone suicide? I think this rule can make a bot much faster - don't know if it has an impact one way or other on the strength. However it's not what is specified. I am quite sure this will impact the speed - and I will look to see how difficult it is to change this with my bot in order to compare numbers. If suicide is not allowed I'd say that criteria #2: 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. should explicitly make mention of suicide not being allowed. It is explicitly mentioned in point 10. However, I agree that point 2 needs clarification. It is technically correct because I say all LEGAL moves except ... but without a careful reading it's easy to read that all empty points except simple ko and eye moves are allowed. - Don Mark On 23-okt-08, at 15:32, Weston Markham wrote: On Thu, Oct 23, 2008 at 1:00 PM, Mark Boon [EMAIL PROTECTED] wrote: This is still something I don't understand. Are there others who implemented the same thing and got 111 moves per game on average? I tried to look through some posts on this list but didn't see any other numbers published. 111 matches my recollection from past experiments that I did with playouts that probably match Don's. I think that this number has been posted previously on the mailing list. Weston ___ 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] From zero to playing on CGOS in 10 minutes
I'm getting close to something I'd like to show people and get feedback. One thing to decide is how to make it public. Previously I used dev.java.net to host my project. But I stopped using it because I had a very slow internet connection and I was getting annoyed with the time it took to communicate with Subversion on the remote host. At the moment I have a bit more decent internet connection, but it's still not fast. Nor reliable. So ideally I'd like to keep the stuff in my local repository. Like a two-step process. I can store versions locally and when I want I can migrate or merge it with the one online. I know ClearCase is ideal for this kind of settup. But too expensive and I doubt there's an online service that supports it. Does anyone know if something like this is possible to setup with Subversion? anyone having experience with something like this? One of the main benefits I see in making a plugin architecture is that I get to configure my bot in an XML file. I simply specify which search strategy to combine with which playout strategy and with what parameters. At some point I had three different search strategies and something like half a dozen different playout strategies. Combine that with potentially different values of K in UCT, a different mercy threshold and who knows what other parameters and it quickly became a real headache to test different configurations against each other. And error-prone. And I'm going to try to do the same with the unit-tests. I have a test-set of some positions to test a MCTS bot. But it soon ran into the same combinatorial problem as above. So I'm planning to make the tests such that you can specify a list of engine-configurations in an XML file, which are then all run past the same test-set. Lastly: I started out making the first pluggable components, which consist of a straightforward UCT-search and a light Monte-Carlo playout strategy that uses pseudo liberties. More components will soon follow. When I run my playouts 1,000,000 times I get the following stats: Komi 7.5, 114.749758 moves per position and Black wins 43.8657%. That's a bit different from the 111 moves and 42% Don got in his reference bot. I haven't looked at Don't implementation (yet) and I wonder what may be different. Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
Mark Boon wrote: I'm getting close to something I'd like to show people and get feedback. One thing to decide is how to make it public. Previously I used dev.java.net to host my project. But I stopped using it because I had a very slow internet connection and I was getting annoyed with the time it took to communicate with Subversion on the remote host. At the moment I have a bit more decent internet connection, but it's still not fast. Nor reliable. So ideally I'd like to keep the stuff in my local repository. Like a two-step process. I can store versions locally and when I want I can migrate or merge it with the one online. I know ClearCase is ideal for this kind of settup. But too expensive and I doubt there's an online service that supports it. Does anyone know if something like this is possible to setup with Subversion? anyone having experience with something like this? How about git or mercurial? Or any other of the distributed SCMs. As your code is open source you could create a public repository for free on http://github.com/ . Urban ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
On Oct 22, 2008, at 11:16 AM, Mark Boon wrote: I'm getting close to something I'd like to show people and get feedback. One thing to decide is how to make it public. Previously I used dev.java.net to host my project. But I stopped using it because I had a very slow internet connection and I was getting annoyed with the time it took to communicate with Subversion on the remote host. At the moment I have a bit more decent internet connection, but it's still not fast. Nor reliable. So ideally I'd like to keep the stuff in my local repository. Like a two-step process. I can store versions locally and when I want I can migrate or merge it with the one online. I know ClearCase is ideal for this kind of settup. But too expensive and I doubt there's an online service that supports it. Does anyone know if something like this is possible to setup with Subversion? anyone having experience with something like this? I have been using git for all of my new projects. It is distributed; users get a clone of the repository. Very fast and proven. Many hosting alternatives are listed here: http://git.or.cz/gitwiki/ GitHosting and it is possible to set up your own hosting if you have a public server. Ian ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
Mark Boon wrote: I'm getting close to something I'd like to show people and get feedback. One thing to decide is how to make it public. Previously I used dev.java.net to host my project. But I stopped using it because I had a very slow internet connection and I was getting annoyed with the time it took to communicate with Subversion on the remote host. At the moment I have a bit more decent internet connection, but it's still not fast. Nor reliable. So ideally I'd like to keep the stuff in my local repository. Like a two-step process. I can store versions locally and when I want I can migrate or merge it with the one online. I know ClearCase is ideal for this kind of settup. But too expensive and I doubt there's an online service that supports it. Does anyone know if something like this is possible to setup with Subversion? anyone having experience with something like this? Subversion 1.4 can do repository replication (see heading svnsync at http://subversion.tigris.org/svn_1.4_releasenotes.html), which should work for a one-way mirroring. There's also svk, http://svk.bestpractical.com, which adds distributed version control on top of subversion. But I really agree with the people recommending git or mercurial. I haven't used mercurial myself yet but I have very positive experience with git. /Gunnar ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
On Wed, 2008-10-22 at 16:16 -0200, Mark Boon wrote: When I run my playouts 1,000,000 times I get the following stats: Komi 7.5, 114.749758 moves per position and Black wins 43.8657%. That's a bit different from the 111 moves and 42% Don got in his reference bot. I haven't looked at Don't implementation (yet) and I wonder what may be different. For one thing, komi is different. I used 0.5 for running this test. I would have use 0.0 but some implementations don't like even komi's. - Don 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] From zero to playing on CGOS in 10 minutes
I use subversion and git. Git mostly for just my own personal repository but it rocks and is my preference. - Don On Wed, 2008-10-22 at 20:28 +0200, Urban Hafner wrote: Mark Boon wrote: I'm getting close to something I'd like to show people and get feedback. One thing to decide is how to make it public. Previously I used dev.java.net to host my project. But I stopped using it because I had a very slow internet connection and I was getting annoyed with the time it took to communicate with Subversion on the remote host. At the moment I have a bit more decent internet connection, but it's still not fast. Nor reliable. So ideally I'd like to keep the stuff in my local repository. Like a two-step process. I can store versions locally and when I want I can migrate or merge it with the one online. I know ClearCase is ideal for this kind of settup. But too expensive and I doubt there's an online service that supports it. Does anyone know if something like this is possible to setup with Subversion? anyone having experience with something like this? How about git or mercurial? Or any other of the distributed SCMs. As your code is open source you could create a public repository for free on http://github.com/ . Urban ___ 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/
[computer-go] From zero to playing on CGOS in 10 minutes
[computer-go] From zero to playing on CGOS in 10 minutes --- Don Dailey drdailey at cox.net --- For one thing, komi is different. I used 0.5 for running this test. I would have use 0.0 but some implementations don't like even komi's. - Don -- -- The 114 length is worrisome. Have you tested it against one of don reference bots ? (I have by the way, great trouble managin all the links and urls everyone gives all the time :) Is there a way to get them such that i can bookmark something and have access to all those ? A wikipage connected with this list maybe ?) Currently my own implementation seems to have the komi wrong somehow. It seems i give one point more to black :) My numbers are a bit higher for black wins than dons. I'll have to investigate i guess. _ Téléphonez gratuitement à tous vos proches avec Windows Live Messenger ! Téléchargez-le maintenant ! http://www.windowslive.fr/messenger/1.asp___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
On Wed, 2008-10-22 at 20:29 -0200, Mark Boon wrote: On Wed, Oct 22, 2008 at 6:07 PM, Don Dailey [EMAIL PROTECTED] wrote: For one thing, komi is different. I used 0.5 for running this test. I would have use 0.0 but some implementations don't like even komi's. But the komi should have no effect on the playout length. I started out with 103 moves, but that was because of a mercy-rule. Without it it's 114. You have 111 rather consistently. And I assume you don't use a mercy-rule. Nor super-ko checking, is that correct? The score is what I was looking at, but you are right about the play-out length because the play-outs don't care what komi is. Do you use the 3X rule? Have you checked the other specs? My guess is that your playouts are not uniformly random - that is very easy to get wrong. Of course that is just a wild guess, it may very well be something completely different. - Don Another thing I have never looked at is AMAF. But that also shouldn't affect playout length I assume. By the way, thanks for all the pointers to 'git from everyone.' It's new to me and at first glance the specs look good, so I'll definitely give it a go. Mark 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/
[computer-go] From zero to playing on CGOS in 10 minutes
Prompted by a few requests I had very recently with regards to the computer-Go framework I once started, plus some free time between a project I just finished and waiting for a visa to start my next, I have started on a project probably best described by the title of this message. Whenever someone looked at my computer-Go framework they invariably where overwhelmed by what was there and didn't know where to begin. And I must say it probably hasn't helped that it's gotten rather intertwined with some of my personal experiments. So it's probably not surprising that it doesn't seem to have too many users. So when Jim O'Flaherty approached me a few days ago about a framework to get new Go programmers started, I decided it may be a nice idea to do just that. A project that can be downloaded, and when instructions are followed a newcomer, someone who hasn't ever programmed Go before, can have a bot that plays random moves up and running in about ten minutes. As Jim pointed out, this potentially not only helps out beginners to get started, but may also provide an easy way for tournament managers to get a bot up and running in a standardized way without the developer needing to be present. (Well, as long as the bot is in Java of course. But other languages may follow this example.) Maybe this is stretching things a bit and ten minutes isn't a whole lot for embarking on what is still one of the most challenging software engineering problems that exists. But I am someone who thinks that barriers are to be broken down and it should be made as easy as possible. I myself have little patience for open-source projects where it takes hours to download, compile and configure a project just to get started. More often than not I give up in frustration. I'm a self-extracting-archive-that-installs-everything type of guy. Otherwise I move on and look for something easier. I think there are already two pieces of excellent software that help the Go programmer today. One is GoGui, which takes a boat-load of work on the front-end out of the hands of aspiring Go programmers. The other is CGOS, which I think is arguably the best platform for testing new ideas against real opponents. But in between the two, connecting with your playing engine in an easy way is still a missing piece, so hopefully this is something I can fill in. There has been much discussion recently about Don's Java reference bot. I think there already exist several of them. Peter Drake has a solid reference implementation with Orego. My framework has one. And there are probably more out there. The problem with all of these is that they still don't really make it easy for someone to start their own. So the last few days I've been busy making a kind of plug-in architecture. All you need to do is provide a JAR with a class that implements an interface of a handful methods and you're ready to put it on CGOS. Or you can use it in combination with GoGui, or twogtp. There are still some loose ends to tidy up before I'll make this public but it probably won't take long. You're still 100% free to design the playing engine any which way you like, but all the communication stuff will be completely take out of your hands. Doing this I have had a few bumps in the road though. And no matter how invaluable I think CGOS is, there are a few (I hope constructive) criticism I'd like to make. I have everything working nicely on my Mac OSX. But on Windows things are problematic. The cgosGTP-win application doesn't work at all. When going to a bit more trouble and tracking down the tclkitsh and using that instead, I see some erratic behaviour. Often it stops after putting out Engine does not support time control commands. Even when it gets past that, I invariably get a broken pipe message as soon as a game starts. Although exactly the same application works fine on a Mac, I'm very willing to believe the problem is on my side. But the problem is I get no feed-back. Whatever error would be put out by my application is not shown on the console. Nor is there any other hint of what could be the matter, it just splurts out a whole lot of junk from some script. I believe it would be a big help if this was improved. Input by others who have experience with this on Windows would be greatly appreciated. Since it takes some time for a new round to start, debugging quickly becomes a very time-consuming business. Before actually putting it out on CGOS, I always do some test-runs with GoGui and the related twogtp, but apparently this is no guarantee to success. So what I'd like to see is a CGOS-mockup implementation. A program that puts a bot through its paces to make sure it completely complies with CGOS before actually going online. I want to stress again, I don't just want to throw some random criticism out there. I want to help improve things. So
Re: [computer-go] From zero to playing on CGOS in 10 minutes
Hi Mark, Very good ideas. I have actually been intending for a long time to give the client a test mode - it would test the bot and and find if there were any problems with your bot as far as GTP or legal moves are concerned. Or perhaps it would even play a random game or two locally as if it were connected to CGOS. The idea would be to act in every way like it was connected even though it wasn't. Then you can debug and get everything right before logging on to CGOS. Believe it or not, I've had the same difficulty when trying to get a new bot up and running. It crashes due to some silly bug and I have to wait another 5-10 minutes for another test. If I don't fix the bug in a hurry, I miss out on the cycle and what a pain it is. - Don On Tue, 2008-10-21 at 22:42 -0200, Mark Boon wrote: Prompted by a few requests I had very recently with regards to the computer-Go framework I once started, plus some free time between a project I just finished and waiting for a visa to start my next, I have started on a project probably best described by the title of this message. Whenever someone looked at my computer-Go framework they invariably where overwhelmed by what was there and didn't know where to begin. And I must say it probably hasn't helped that it's gotten rather intertwined with some of my personal experiments. So it's probably not surprising that it doesn't seem to have too many users. So when Jim O'Flaherty approached me a few days ago about a framework to get new Go programmers started, I decided it may be a nice idea to do just that. A project that can be downloaded, and when instructions are followed a newcomer, someone who hasn't ever programmed Go before, can have a bot that plays random moves up and running in about ten minutes. As Jim pointed out, this potentially not only helps out beginners to get started, but may also provide an easy way for tournament managers to get a bot up and running in a standardized way without the developer needing to be present. (Well, as long as the bot is in Java of course. But other languages may follow this example.) Maybe this is stretching things a bit and ten minutes isn't a whole lot for embarking on what is still one of the most challenging software engineering problems that exists. But I am someone who thinks that barriers are to be broken down and it should be made as easy as possible. I myself have little patience for open-source projects where it takes hours to download, compile and configure a project just to get started. More often than not I give up in frustration. I'm a self-extracting-archive-that-installs-everything type of guy. Otherwise I move on and look for something easier. I think there are already two pieces of excellent software that help the Go programmer today. One is GoGui, which takes a boat-load of work on the front-end out of the hands of aspiring Go programmers. The other is CGOS, which I think is arguably the best platform for testing new ideas against real opponents. But in between the two, connecting with your playing engine in an easy way is still a missing piece, so hopefully this is something I can fill in. There has been much discussion recently about Don's Java reference bot. I think there already exist several of them. Peter Drake has a solid reference implementation with Orego. My framework has one. And there are probably more out there. The problem with all of these is that they still don't really make it easy for someone to start their own. So the last few days I've been busy making a kind of plug-in architecture. All you need to do is provide a JAR with a class that implements an interface of a handful methods and you're ready to put it on CGOS. Or you can use it in combination with GoGui, or twogtp. There are still some loose ends to tidy up before I'll make this public but it probably won't take long. You're still 100% free to design the playing engine any which way you like, but all the communication stuff will be completely take out of your hands. Doing this I have had a few bumps in the road though. And no matter how invaluable I think CGOS is, there are a few (I hope constructive) criticism I'd like to make. I have everything working nicely on my Mac OSX. But on Windows things are problematic. The cgosGTP-win application doesn't work at all. When going to a bit more trouble and tracking down the tclkitsh and using that instead, I see some erratic behaviour. Often it stops after putting out Engine does not support time control commands. Even when it gets past that, I invariably get a broken pipe message as soon as a game starts. Although exactly the same application works fine on a Mac, I'm very willing to believe the problem is on my side. But the problem is I get no feed-back. Whatever error would be put out by my
Re: [computer-go] From zero to playing on CGOS in 10 minutes
You could have a copy of CGOS running on a different port that pairs up anything that connects to it against itself and starts a new game as soon as the first game ends. Don Dailey wrote: Hi Mark, Very good ideas. I have actually been intending for a long time to give the client a test mode - it would test the bot and and find if there were any problems with your bot as far as GTP or legal moves are concerned. Or perhaps it would even play a random game or two locally as if it were connected to CGOS. The idea would be to act in every way like it was connected even though it wasn't. Then you can debug and get everything right before logging on to CGOS. Believe it or not, I've had the same difficulty when trying to get a new bot up and running. It crashes due to some silly bug and I have to wait another 5-10 minutes for another test. If I don't fix the bug in a hurry, I miss out on the cycle and what a pain it is. - Don On Tue, 2008-10-21 at 22:42 -0200, Mark Boon wrote: Prompted by a few requests I had very recently with regards to the computer-Go framework I once started, plus some free time between a project I just finished and waiting for a visa to start my next, I have started on a project probably best described by the title of this message. Whenever someone looked at my computer-Go framework they invariably where overwhelmed by what was there and didn't know where to begin. And I must say it probably hasn't helped that it's gotten rather intertwined with some of my personal experiments. So it's probably not surprising that it doesn't seem to have too many users. So when Jim O'Flaherty approached me a few days ago about a framework to get new Go programmers started, I decided it may be a nice idea to do just that. A project that can be downloaded, and when instructions are followed a newcomer, someone who hasn't ever programmed Go before, can have a bot that plays random moves up and running in about ten minutes. As Jim pointed out, this potentially not only helps out beginners to get started, but may also provide an easy way for tournament managers to get a bot up and running in a standardized way without the developer needing to be present. (Well, as long as the bot is in Java of course. But other languages may follow this example.) Maybe this is stretching things a bit and ten minutes isn't a whole lot for embarking on what is still one of the most challenging software engineering problems that exists. But I am someone who thinks that barriers are to be broken down and it should be made as easy as possible. I myself have little patience for open-source projects where it takes hours to download, compile and configure a project just to get started. More often than not I give up in frustration. I'm a self-extracting-archive-that-installs-everything type of guy. Otherwise I move on and look for something easier. I think there are already two pieces of excellent software that help the Go programmer today. One is GoGui, which takes a boat-load of work on the front-end out of the hands of aspiring Go programmers. The other is CGOS, which I think is arguably the best platform for testing new ideas against real opponents. But in between the two, connecting with your playing engine in an easy way is still a missing piece, so hopefully this is something I can fill in. There has been much discussion recently about Don's Java reference bot. I think there already exist several of them. Peter Drake has a solid reference implementation with Orego. My framework has one. And there are probably more out there. The problem with all of these is that they still don't really make it easy for someone to start their own. So the last few days I've been busy making a kind of plug-in architecture. All you need to do is provide a JAR with a class that implements an interface of a handful methods and you're ready to put it on CGOS. Or you can use it in combination with GoGui, or twogtp. There are still some loose ends to tidy up before I'll make this public but it probably won't take long. You're still 100% free to design the playing engine any which way you like, but all the communication stuff will be completely take out of your hands. Doing this I have had a few bumps in the road though. And no matter how invaluable I think CGOS is, there are a few (I hope constructive) criticism I'd like to make. I have everything working nicely on my Mac OSX. But on Windows things are problematic. The cgosGTP-win application doesn't work at all. When going to a bit more trouble and tracking down the tclkitsh and using that instead, I see some erratic behaviour. Often it stops after putting out Engine does not support time control commands. Even when it gets past that, I invariably get a broken pipe message as soon as a game starts. Although exactly the same application works fine on a Mac, I'm very
Re: [computer-go] From zero to playing on CGOS in 10 minutes
On 21-okt-08, at 23:11, Michael Williams wrote: You could have a copy of CGOS running on a different port that pairs up anything that connects to it against itself and starts a new game as soon as the first game ends. I don't know if it's a good idea to have it run against itself. I'm not even sure how that would work. It may open a whole new can of worms. But if there's another port where there's always a random bot ready to pair up to that would already help. Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
Of course the server code is available on sourceforge, so you can set up your own test site. But I think all of that can be simulated with a smarter client. The only think missing is the actual connection to the server. But this is for debugging the bots mostly. - Don On Tue, 2008-10-21 at 23:28 -0200, Mark Boon wrote: On 21-okt-08, at 23:11, Michael Williams wrote: You could have a copy of CGOS running on a different port that pairs up anything that connects to it against itself and starts a new game as soon as the first game ends. I don't know if it's a good idea to have it run against itself. I'm not even sure how that would work. It may open a whole new can of worms. But if there's another port where there's always a random bot ready to pair up to that would already help. Mark ___ 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/
