What I tried was not a tree based version, so it's a very poor substitute.
I observed in private testing that even 10 playouts crushes 1 playout in a simple non-tree based bot. So what I tried was doing recursive playouts - instead of playing move randomly in the playouts each move in the playouts was decided by it's own set of playouts. It was a quick and dirty experiment, and I did not stick with it long enough to do it justice, so I probably only tried naive versions of it. What I did try did not work well at all. - Don On Thu, Jun 11, 2009 at 3:21 PM, Michael Williams < [email protected]> wrote: > I tried it in my previous engine, which while probably littered with bugs, > at least had the characteristic that more playouts lead to better play. > This test was extremely slow and produced a weaker bot. YYWV. > > I'm 95% sure Don mentioned it on this list a couple of years ago, but I > don't know if he actually tried it. > > > Gian-Carlo Pascutto wrote: > >> On Wednesday 10 June 2009 18:48:55 Martin Mueller wrote: >> >> Currently, we try to sidestep this fundamental problem by replacing >>> local search with local knowledge, such as patterns. But that does not >>> fully use the power of search. >>> >> >> So, has anyone tried recursive UCT (using UCT again in the playouts), and >> what were the results? I saw some results for uninteresting games, but >> nothing about Go. >> >> > _______________________________________________ > computer-go mailing list > [email protected] > http://www.computer-go.org/mailman/listinfo/computer-go/ >
_______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
