On Thu, 2007-04-12 at 15:25 +0200, Łukasz Lew wrote: > > * In a real game, the tree (i.e. the uct_t object) is thrown away by > > each call to genmove. Wouldn't it be better to make this a global, > and > > then when a move is chosen just delete the sub-trees for the moves > that > > weren't chosen. > > > > Pros: It will start with a more informative tree, instead of having > to > > build it from scratch each time. This should be the equivalent of an > > extra 20-50% playouts, for free.
Lazarus does this, but after the opponent moves, there is very little tree remaining. I do this out of general principle (might as well take the free tree no matter how tiny) but in practical terms I doubt it adds more than 5 ELO points to the program. But there is another way to make it pay off more reasonably. After you make a move, kill all the siblings and start thinking as if you were the opponent. Then when it's your turn again, prune the tree again to the relevant branches. Then you will get a modest improvement. However, Lazarus thinks on the opponent time by assuming the program will play what Lazarus thinks is best. I did some informal calculations and I believe this is more effective. Lazarus get the full benefit of the opponents time if it predicts correctly, otherwise almost no benefit but it is able to predict a lot of moves, especially in sharp positions where this is important. > > Cons: More code complexity. Also, the program can start playing more > > weakly if the user uses undo_move() a lot (not weaker than without > the > > idea, but it may be more confusing). > > > > Note: More memory usage, but no different to if number of playouts > were > > increased, so I don't think this is a con. > > It's a good idea, It was a next thing on my UCT to-do list. But as I > said before. > uct.cpp is very far in quality from the rest of libego library. > _______________________________________________ computer-go mailing list [EMAIL PROTECTED] http://www.computer-go.org/mailman/listinfo/computer-go/
