[Computer-go] Computer Analysis of Master Games ?!
pasky at ucw.cz
Tue Aug 10 03:37:23 PDT 2010
On Tue, Aug 10, 2010 at 11:29:54AM +0200, "Ingo Althöfer" wrote:
> Petr Baudis <pasky at ucw.cz>
> > On Mon, Aug 09, 2010 at 09:19:35AM -0700, terry mcintyre wrote:
> > > Interesting! Is it feasible to automatically generate such graphs for
> > > a large number of games?
> > It depends on the number of time you want to spend per move.
> It might be an over-night job for a PC: you give him a list
> of a few hundred games in the evening, and in the morning you
> can study the results. ManyFaces needs about 30 seconds for a
> normal game. So, 120 sgf per hour; 1,000 sgf in an 8-hours night slot.
Hmm, that is extremely fast, it has to be spending very little time per
move. I think it's useful to have higher accuracy and much less sgf.
I've left a test-run with various number of simulations per move running
overnight, I'm attaching the plot.
> My proposal would be to include also a score estimator curve.
> Both diagrams together (win rates and scores) give a better clue
> about what is going on.
If your program has a score estimator... I don't think there are any
good ones though. Pachi with special dynkomi setup actually could act as
one, but that would also double
> > > Next question: where do current programs fail to determine who is
> > > in the lead? Why?
> > That's a good one!
> Some people may contribute in this context by looking at hundreds of such
> diagrams: filtering out the most interesting ones and investigating
> the corresponding games.
Yes, and I don't think looking at hundreds is neccessary, just looking
at a few should already bring up interesting stuff. :)
> Can you modify it so that not only the positions with White to
> move are evaluated but all positions?
Originally, it was like that, but it just produced more dented graphs
since due to minimax, white winrate with w-to-play is usually higher
than white winrate with b-to-play - there seems to be little extra
information. I wonder why the same effect is not visible in the
> Another thought:
> Many chess programs have a feature for analysing whole games.
> Typically, they do this analysis from the end of a game to the start.
> In between, they do NOT clear the hash tables but use the search
> results from move t+1 (and also those from t+2 ...) to speed up and
> improve the search at move t.
> Maybe, a similar approach would improve MCTS search: using the
> tree from move t+1 for the MCS search at wove t.
> At least for quick thinking times memory size should not become
> a problem here.
I see. But frankly, this would require much more work to get working in
Pachi and I'm not that motivated. :-)
Petr "Pasky" Baudis
The true meaning of life is to plant a tree under whose shade
you will never sit.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 8074 bytes
Desc: not available
More information about the Computer-go