> G'day guys, > I'm involved in the development of a very powerful and flexible grid > software, which we plan to release in January. It is all java based. > http://www-nereus.physics.ox.ac.uk/ (bear in mind you can't download > it yet and the website is out of date)
> One of the things I'd like to do on it, once it is finished, is some > kind of attack on Go. I've messed around trying to genetically > generate algorithms to play go. However this has had to go on the back > burner for the moment. The brief attempt I made had no way of storing > data between games (I ran out of time) and the best algorithm it came > up with was a purely random algorithm... :-) > our group is also the one that is doing JPC - http://www-jpc.physics.ox.ac.uk/ > I'd love to hear about anyone else distributed attacks on Go. > cheers, > Ian Hi, ???? Funny: I was just getting ready to dust off my GA again. ???? It sounds like you are looking for an interesting application that will motivate people to volunteer computer time and draw some notice to your project. If it were me, I would want to make a distributed version of a Monte-Carlo/UCT go engine and have it play some exhibition games against strong human players. ???? The social engineering qualities are good. I think?there would be a fair amount of (short term) interest from people who could have their computer helping in such a contest. And it would be easy to give them some feedback about how the game was going and what their computer was doing. ???? Play-by-mail, one turn a day, might be acceptable. Tournament time limits would be much more dramatic. milestone 1: All network-nodes compute pure Monte-Carlo (no search tree) scores for the possible moves, the scores are combined centrally to pick the move. It's easy, it will wring out the system, and the bandwidth is low. The playing performance will always be poor because this algorithm doesn't scale well. milestone 2: Each network-node builds its own tree using UCT, but information is only combined at the root. This version will play much better because each node is smarter. The bandwidth will be higher. I can only guess at the scaling behavior, but this milestone might be the 80% solution. milestone 3: Information from the search-nodes is shared between network-nodes, but only for search-nodes close to the root of the tree. Sounds innocent enough. You just limit the shared nodes to the first couple of plys. But it's a trap that will suck you in: best scaling behavior requires too much communication-but what if you made each Monte-Carlo simulation smarter...? ??? I'm just throwing the idea out there. I expect and invite others on the list to point out its flaws. - Dave Hillis . ________________________________________________________________________ Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection.
_______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
