Thanks very much, I'm reading through the thesis now. It's great to have some research to refer to and build off of, although it's daunting to know it didn't work out that well for you. I hope I'm not going into a dead end! Is there by any chance some source code available, just to read through / test against?
On Mon, Jun 22, 2009 at 1:08 PM, Martin Mueller <mmuel...@cs.ualberta.ca>wrote: > Hello Tom, > > I worked on this 15 years ago during my PhD thesis. It works very well if > the subgames are separate, but I could not get it to work in real Go. I > think it is doable but hard. The 3x3 probably do not have enough context to > compute temperatures except the very late endgame, since that will depend on > the weak blocks and groups. > > You might want to look at my PhD thesis on > http://www.cs.ualberta.ca/~mmueller/publications.html#1995<http://www.cs.ualberta.ca/%7Emmueller/publications.html#1995> > > The topic is still of great interest for me, even though I have not worked > on it for a while. So let me know what you find out, and if I can help. > > Martin > > Hi, I've decided to build a go program based on combinatorial game theory, > And I'm looking for any pointers or advice that might save me trouble > later. I looked a little in the archives, and while there are references to > CGT in a few places, I haven't seen any attempts to build a full engine > around it. I found cgsuite at http://cgsuite.sourceforge.net/, which is > very helpful for understanding the underlying algorithms and source code. > Has anyone tried this before, and do they have some warnings or advice to > share? My basic plan is this: > > In the beginning, partition the board into hard "subgames" maybe 3x3 blocks > or similar. Calculate the temperature for each subgame, and play > thermostrat as described. I don't expect this program to play very well, > but it should be lightning fast: at each move, only the local subgame needs > to be re-evaluated (and perhaps adjacent subgames, since captures may run > across the games). > > Once that code works, I want to start on the hard part: dynamically > resizing the subgames based on play. I imagine in the early game there's > really only one game, and as midgame approaches the board slowly breaks up > into mostly independant chunks. I haven't worked out the details of this > yet, but my basic idea is to start with very small subgames and merge them > when it seems likely two games affect each other, using some heuristics > based on shared liberties, etc. > > Well, that's my idea, does it sound like it my work? > >
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
