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. :-)
--
Petr "Pasky" Baudis
Sick and yet happy, in peril and yet happy, dying and yet happy,
in exile and happy, in disgrace and happy. -- Epictetus
_______________________________________________
Computer-go mailing list
[email protected]
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
