Hello Don, > The improvement over a given opponent should be measured by ELO points, > not win percentage unless you do the extra math. I cannot quite tell if > you were considering that or not - if so then ignore this. Going from > 50% wins to 60% with is a modest improvement, but going from 80% to 90% > is a MAJOR improvement. Yes, I totally agree, and I am sorry I did not emphasis that more. It is also a reason why you need much more games to see a statistically significant improvement when you are close to 90% (even if the variance is lower) because 1% is very important.
> UCI is completely scalable, but may not be optimally scalable. It may > turn out that there are other ways to handle the best first search. My > fear with UCI type methods is that it might be progressively less > efficient as you get much faster. It is probably a matter of finding > just the right formula for allocating work. > Or it might turn out that some form of alpha/beta search using > monte/carlo as an evaluator is the right thing given enough power - > which suggests some kind of hybrid approach. UCI may be the best way > to handle nodes closer to the leaf and perhaps be viewed as a kind of > quies search for a standard alpha/beta engine. I'm just taking a wild > guess here. I assume by "UCI" you mean UCT. I think with a lot of computation power, when the tree is very deep, alpha beta would work better than UCT. For example, if you have enough computation power to explore all the minmax tree (which can be the case at the end of the game), alpha beta will give the results faster than UCT at least if you don't make it more exploratory (with the "famous" 1/10 constant in the formulae, UCT makes more exploitation). It is because before going deeper on one move, if the reward by the MC simulation is bad, you have to wait until the "log n" term saves you. So if we had a lot more power, or at in the end of the game alpha beta or a variant would be a better choice. Still at the end of the game, UCT with MC is already very good. Perhaps an hybrid approach would be good. However I don't think it is where we must put the higher priority. In 19x19 we are far from having enough power, so other solutions have to be found. Perhaps for playing almost perfectly on a game like 7x7, hybrid approaches might be great. Sylvain > On Thu, 2006-11-23 at 13:24 +0100, [EMAIL PROTECTED] wrote: > > > I think they will play very strong. Sofar all my tests indicates nice > > > scaling, but I admit I have not tried a proper experiment for a long > > > time since I do not have any extra hardware. Perhaps the Mogo team > > > could do something but the problem is that Mogo is so strong it would > > > beat most programs 100% with modest increases in computation time on > > > 9x9. > > > > What we can say from experiments is that the scaling with time is very > > good with few simulations, but becomes less interesting with a lot of > > simulations. With the same settings (not the best, but the ones for which > > we have the most number of results), against gnugo at level 0 (s/m == > > simulations/move): 3000 s/m : 35%, 10000 s/m : 60%, 70000 s/m : 90%. > > Against gnugo at level 8 (default) it gives respectively 50% and 80% for > > 10k s/m and 70k s/m. MoGo on cgos plays with something like 300k s/m, but > > I don't think it is much better than with 70 k s/m. Quick experiments > > showed that the improvement was only few % against gnugo. However, I saw > > that the improvement is larger against MC based programs (classical non > > transitivity of the results), and against itself it is huge. > > I also saw that after each improvement, the number of simulations was > > less important than before, so the scaling is less impressive. > > Perhaps it comes from the fact that now the opening moves are those where > > MoGo loses most of its games and, as Magnus said, the number of > > simulations are not so important in the opening. We did not investigate > > that. > > > > Sylvain > > > > _______________________________________________ > > computer-go mailing list > > computer-go@computer-go.org > > http://www.computer-go.org/mailman/listinfo/computer-go/ _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
