On Mon, Nov 12, 2007 at 05:31:11PM +0100, Petr Baudis wrote: > > > > I may be wrong, but I suspect most of bots specify the total number of > > simulations to play, not per move candidate. Thus, your '1000' should be > > compared against a '81000' in the beginning of the game. That sounds like an > > overly large number to me. > > Oh! I must have misunderstood the Monte Carlo algorithm description in > that case.
It could also be me who is wrong! I am just an amateur hanging at the fringe of the computer go world, programming small experiments with go when I am not too tired from my daily programming job... > I intentially tried to come up with the simplest MonteCarlo-like > algorithm possible - it is supposed to be an example engine, after all. > Are there other possible algorithms for the MonteCarlo approach? > (Apart of UCT; that's the next step.) There is the "all moves as first" (AMAF), that counts a win or loss not only to the move that started the random playout, but to every move that was played in that playout. Somewhat weaker, they say, but gets good results quicker (in a smaller number of simulations). > I have had it play games on KGS over the day but I still don't have much > idea about its strength. I would say maybe around 15k, but mostly too > strong people play it and the weaker ones escape or undo (I have > disallowed that now). Why don't you play it on cgos, that is where most go programs meet? http://cgos.boardspace.net/ > It used to be nice code; as I desperately tried to optimize it, the code > got somewhat uglier in some parts. (I got it from initial 650 games per > second to 2500 gps, though!) You might not like the foreach macros. ;-) I have to live with such macros in the libego code as well. As long as I don't have to use them everywhere in my own code, I don't mind. And as long as there are decent interfaces to the functions, I don't really care how ugly the insides are coded. > The framework and the example engines are MIT-licensed (almost public > domain); I believe this is just something that noone should have to > reimplement yet another time, no matter how evil they are. If I get some > really well-performing engine built on top of it, I might license that > one under GPL or keep the code for myself, depending how evil *I* will > feel. GPL is fine with me. I only want to be able to make my experiments and show the world how I did it, in case I get some interesting results. > Since I have a nice number of my university department machines > available at night, I'm currently working on support for low-level > parallelization over many hosts in the infrastructure. I wonder if I can > dig out shells on at least 81 machines... ;-) Interesting. But since those are not going to be equally powerful, nor equally close to your master machine, I suspect there could be a more efficient way to distribute the job among them, than just giving one candidate move to each. Why not let each of them try all possible moves, and report their results back after a given time. Simply sum up the results, and choose the best. That way you can use as many or as few machines as you happen to have at hand, and the fast ones don't need to wait for the slower ones. But I think MC is so fast that this will not pay off. I seem to recall that the quality of play does not improve much over 5000 play-outs, anyway. -H -- Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
