gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] more top-level search results


From: Douglas Ridgway
Subject: Re: [gnugo-devel] more top-level search results
Date: Tue, 14 Sep 2004 20:48:47 -0600 (MDT)

On Thu, 9 Sep 2004, Evan Daniel wrote:

> On Thu, 9 Sep 2004 14:30:03 -0600 (MDT), Douglas Ridgway
> <address@hidden> wrote:
> 
> > Questions:
> > 
> > 1. With these parameters, each game takes a few hours. Am I right in
> > thinking that the same tactical searches are being redone, over and over,
> > so there might be substantial performance gains possible?
> 
> The GNU Go persistent caching should take care of some of this,
> particularly if you use the same GNU Go process for all variations. 
> You might try increasing the size of the persistent caches and see if
> that helps.

I did some quick tests, on a fairly early position (move 14) with topwidth
5, subwidths up to 5, depths up to 4, and found slight increases in run
time going from -M 8 to -M 24, and a larger increase going to -M 96, i.e.
no benefit from increased cache size. The same GNU Go process is used for
all variations, and the code uses the GNU Go GTP commands gg_genmove,
top_moves, is_legal, play, estimate_score, and undo. Might one of these
wipe the cache, or perhaps there's just nothing useful in the cache for
searches near that particular position? I should probably try some other
positions too. For what kind of position should I see a big effect?

> > 2. Are there tools for identifying substantially similar games?
> 
> When doing such runs I ignored the substantially similar games and
> checked for exact duplicates by removing all non-move information from
> the SGFs and then comparing MD5 sums.

Here's yet another datapoint on repeats. At width 5, depth 4 I finished a
set of 70 games at H2 against level 12, a continuation of what I posted
before. Including repeats, it's W 49, B 21, a nice substantial difference.
If a repeat is defined as same final score and same Dyer signature and one
counts only unique games, it's W 9, B 8, i.e.  only 17 unique games in 70
played. Dyer signature will ignore some small differences, which is good,
but may also differ for some games which are just as nearly identical.

In any case, it's clear that the games I'm able to generate so far are
much less independent than is needed to evaluate algorithms statistically.

doug.


Here's the most popular game, which got played 31 times:

(;GM[1]FF[4]RU[Japanese]SZ[19]HA[2]KM[0.5]RE[W+R]
PW[GTP.tcl script running GNU Go v. 3.5.10 0.1 (random seed 
1094258617)]PB[GNU Go 3.5.10 (random seed 1094258617)]
AB[pd]AB[dp]
;W[dn] ;B[fp] ;W[cp] ;B[cq] ;W[pf] ;B[nd] ;W[qd] ;B[qc] ;W[qp] ;B[qe]
;W[nq] ;B[co] ;W[lc] ;B[dd] ;W[gd] ;B[df] ;W[ec] ;B[dc] ;W[eb] ;B[nc]
;W[hq] ;B[fq] ;W[qj] ;B[db] ;W[kq] ;B[nf] ;W[ch] ;B[cf] ;W[ck] ;B[ld]
;W[jc] ;B[nh] ;W[ok] ;B[mk] ;W[ph] ;B[nm] ;W[ml] ;B[kk] ;W[km] ;B[je]
;W[hd] ;B[fn] ;W[cn] ;B[bp] ;W[ll] ;B[io] ;W[bg] ;B[bf] ;W[hh] ;B[lk]
;W[ko] ;B[kd] ;W[ho] ;B[kc] ;W[kb] ;B[hn] ;W[ip] ;B[go] ;W[mb] ;B[rg]
;W[da] ;B[ca] ;W[ea] ;B[bb] ;W[pa] ;B[bn] ;W[ek] ;B[cm] ;W[eh] ;B[jh]
;W[og] ;B[ng] ;W[dm] ;B[bm] ;W[hp] ;B[ob] ;W[in] ;B[im] ;W[jn] ;B[gm]
;W[oa] ;B[ri] ;W[rj] ;B[aj] ;W[gr] ;B[ff] ;W[gi] ;B[sj] ;W[sk] ;B[nb]
;W[na] ;B[mc] ;W[lb] ;B[pb] ;W[qa] ;B[rb] ;W[nj] ;B[mi] ;W[fl] ;B[ed]
;W[fd] ;B[fr] ;W[ik] ;B[hk] ;W[fs] ;B[hj] ;W[il] ;B[hl] ;W[ds] ;B[jl]
;W[jm] ;B[hm] ;W[kl] ;B[jk] ;W[ii] ;B[hi] ;W[eg] ;B[ef] ;W[qf] ;B[rf]
;W[ih] ;B[jg] ;W[ji] ;B[ic] ;W[ib] ;B[jd] ;W[hc] ;B[jb] ;W[ja] ;B[jc]
;W[ia] ;B[qb] ;W[si] ;B[gb] ;W[ga] ;B[sh] ;W[cl] ;B[ij] ;W[bj] ;B[ak]
;W[ai] ;B[al] ;W[qi] ;B[rh] ;W[fe] ;B[gf] ;W[gg] ;B[ag] ;W[ki] ;B[kh]
;W[ah] ;B[gj] ;W[oe] ;B[fi] ;W[gh] ;B[ej] ;W[ne] ;B[pe] ;W[of] ;B[me]
;W[dj] ;B[ei] ;W[di] ;B[br] ;W[ni] ;B[fk] ;W[af] ;B[el] ;W[ae] ;B[hf]
;W[dk] ;B[em] ;W[en])

To count unique games w/ a particular result, I do something like:

 cat `grep 'RE\[W+R' *.sgf | cut -d : -f 1` > t
 sgfc -d28 -g t | grep signature | cut -d ' ' -f 6-7 | sort | uniq | wc -l







reply via email to

[Prev in Thread] Current Thread [Next in Thread]