Thanks a lot for sharing so much information. I am checking all your suggestions :)
I wonder, if the biggest difference between fuego, oakfoam compared to pachi is not the use of progressive widening?! This might be narrowing the search very good for low number of playouts, but becoming useless later?! Detlef Am Freitag, den 20.12.2013, 12:59 +0100 schrieb Petr Baudis: > Hi! > > On Thu, Dec 19, 2013 at 10:23:05AM -0700, Martin Mueller wrote: > > I assume this is on 19x19? Yes, it is also my experience that pachi scales > > better than Fuego on the big board. > > I suspect that a big part of it is large patterns, which Fuego does not yet > > have. But it is also possible that something else contributes to better > > scaling, such as the UCT formula. > > In general, for scaling, the best tradeoff is to minimize bias at the > expense of slower convergence. How to accomplish this is of course a > difficult question, e.g. more randomness does not always mean less bias. > > Two things may help: (i) in Pachi, I always tried to make all decisions > noisy; almost no rule in the playout is applied 100% of the time. > (ii) there is rather involved code for reducing bias in some common > tactical situations; I think many other programs don't have that much of > this (though at least Zen probably does, I'd expect; maybe CS as well). > As an interesting experiment, you might wish to test scaling with > modified Pachi that has 'return false;' at the top of > is_bad_selfatari_slow() body in tactics/selfatari.c. > > Out Pachi paper may also contain some ideas; it lists Elo effect of some > of Pachi's heuristics with various time allowances; e.g. strength > contribution of playout-heuristic tree prior is mostly constant, but CFG > prior is more important with more time. > > But the biggest difference may be that Pachi had the enormous luxury > of having its parameters historically tuned with similar game conditions > as in real games, rather than the usual low-performance blitz, thanks > to Jean-loup Gailly. You may find some of the parameter changes in > history (e.g. 49249d but not only), but I'm not sure if there are clear > or universal lessons in that and understanding the parameter semantics > might involve reading a lot of Pachi's code. > > > My two conjectures are that 1. using knowledge from large patterns > > decreases the effective branching factor in pachi, and/or 2. patterns allow > > it to focus on better moves, improving the quality of the tree. > > I think part 2. is relatively clear. Part 1. is not clear to me. > > I'm not sure there is a simple answer. One thing is that in low-end > scenario, optimum pattern prior is *10 to *20 the usual prior, while > in high-end scenario, optimum pattern prior is just *4 the usual prior. > [1] So leaning heavily on patterns will make Pachi focus too much on > just nice shapes. But I'd be surprised if the optimum moved much further > down when going above the high-end scenario. > > [1] But it's also confounded by the fact that *20 pattern prior was > when testing against GNUGo while *4 pattern prior was against Fuego. > Performance data is not always perfect. :-) > _______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
