win7x64 pachi -t =5000:15000 --dcnn=df
Pachi 12.40 (Jowa)
git a372ddf (master)
x86-64 dcnn build, Mar 31 2019

Random seed: 1554190993
F0402 20:00:33.743199 24000 layer_factory.hpp:81] Check failed: registry.count(type) == 1 (0 vs. 1) Unknown layer type: Reshape (known types: Convolution, Flatten, Input, ReLU, Softmax)
*** Check failure stack trace: ***
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

D:\Downloads\Pachi>

How do you use Lizzie?

Doesn't compile (because that PC is local only) - I had downloaded zip archive and extracted its content. While bazel build:

ERROR: error loading package...

How to compile on local PC (OS: openSUSE Tumbleweed)?

Thanks in advance.

Hi,

Came across this game yesterday: (sgf)

Pachi (black) has a sure 2.5pt win, winrate is consistently above 70% (95% for past 2 moves)
yet inexplicably drops after oponent plays dame, and resigns: (full log here)

IN: genmove b
Move:  261  Komi: 0.5  Handicap: 2  Captures B: 5 W: 11
      A B C D E F G H J K L M N O P Q R S T        A B C D E F G H J K L M N O P Q R S T  
    +---------------------------------------+    +---------------------------------------+
 19 | . X X O . O O X . . . . . . . . . . . | 19 | X X X O O O O X X X X X X X X X X X X |
 18 | . X O O O O X X . . . . X O X . . . . | 18 | X X O O O O X X X X X X X X X X X X X |
 17 | . X X O X O O X X . O . X O X . . X . | 17 | X X X O X O O X X X X X X X X X X X X |
 16 | . X X X X O O O X . X X X X O X X . . | 16 | X X X X X O O O X X X X X X O X X X X |
 15 | X X X O O O . O X . O X O O O O X . . | 15 | X X X O O O O O X X X X O O O O X X X |
 14 | O O X X O)O O X X X X O . . . X O X . | 14 | O O X X , O O X X X X O O O O O O X X |
 13 | O . O X X O X O X O X O . O O O O X . | 13 | O O O X X O X O X O X O O O O O O X X |
 12 | . . O X . X X O O O O O X X X O X X . | 12 | O O O X X X X O O O O O O O O O X X X |
 11 | . . O X X . X O . O X . . . O . O X . | 11 | O O O X X X X O O O O O O O O O O X X |
 10 | O O . O X X O . O O . . . . O . O O X | 10 | O O O O X X O O O O O O O O O O O O X |
  9 | O O . O X O O O O X O . . . O . . O X |  9 | O O O O X O O O O X O O O O O O O O X |
  8 | O X O O O O X O X X O . . . O . O X . |  8 | O X O O O O X O X X O O O O O O O X X |
  7 | X X O X O O X X X O . . . . O O O X . |  7 | X X O X O O X X X O O O O O O O O X X |
  6 | X X X X X X X X X O . . . . O X X X . |  6 | X X X X X X X X X O O O O O O X X X X |
  5 | X O O O X . X O O O . . . . . O O X . |  5 | X O O O X X X O O O O O O O O O O X X |
  4 | O O O X . . X O X O . O O . . O X . . |  4 | O O O X X X X O X O O O O O O O X X X |
  3 | . . O X X O X X X O O O X O O O X . . |  3 | O O O X X X X X X O O O X O O O X X X |
  2 | . O O O X X . . X X O X X X O X X . . |  2 | O O O O X X X X X X O X X X O X X X X |
  1 | . . O O O X . . . . X . X . X . X . . |  1 | O O O O O X X X X X X X X X X X X X X |
    +---------------------------------------+    +---------------------------------------+

prior_dcnn(pass) = [ Q1 K1 A2 B13 O1 ]      [ 0.71 0.10 0.03 0.02 0.01 ]
(UCT tree; root white; extra komi 0.000000; max depth 7)
[pass] 0.232/5004 [prior 0.000/0 amaf 0.000/0 crit -0.768 vloss 0] h=0 c#=115 <26f04c36014ea48e>
 [Q1] 0.096/1461 [prior 0.991/1131 amaf 0.260/6185 crit 0.001 vloss 0] h=0 c#=112 <26f04c42014ea49a>
  [A2] 0.076/1262 [prior 0.278/36 amaf 0.085/4074 crit -0.000 vloss 0] h=0 c#=113 <26f04cb5014ea50d>
   [O6] 0.194/345 [prior 0.944/180 amaf 0.111/2235 crit -0.314 vloss 0] h=0 c#=110 <26f05213014eaa58>
    [N8] 0.150/234 [prior 0.064/157 amaf 0.179/834 crit 0.000 vloss 0] h=0 c#=111 <26f052f8014eab3d>
    [O5] 0.188/85 [prior 0.079/126 amaf 0.163/498 crit -0.000 vloss 0] h=0 c#=111 <26f052eb014eab30>
   [M11] 0.007/144 [prior 0.942/173 amaf 0.060/1984 crit -0.403 vloss 0] h=0 c#=110 <26f0522e014eaa73>
    [L10] 0.007/135 [prior 0.080/125 amaf 0.007/411 crit -0.000 vloss 0] h=0 c#=111 <26f053e6014eac27>
   [F4] 0.018/114 [prior 0.923/130 amaf 0.070/1438 crit -0.000 vloss 0] h=0 c#=109 <26f05203014eaa48>
    [L10] 0.010/103 [prior 0.082/122 amaf 0.010/315 crit 0.000 vloss 0] h=0 c#=111 <26f054c5014ead04>
   [A3] 0.022/91 [prior 0.684/95 amaf 0.048/610 crit -0.978 vloss 0] h=0 c#=110 <26f051fe014eaa43>
    [B3] 0.025/81 [prior 0.082/122 amaf 0.024/246 crit -0.000 vloss 0] h=0 c#=111 <26f056cc014eaf08>
   [K16] 0.047/86 [prior 0.939/165 amaf 0.072/2183 crit -0.001 vloss 0] h=0 c#=109 <26f05242014eaa87>
    [P14] 0.039/76 [prior 0.077/130 amaf 0.043/235 crit 0.000 vloss 0] h=0 c#=111 <26f05c43014eb46e>
   [A1] 0.000/81 [prior 0.684/95 amaf 0.028/527 crit -1.000 vloss 0] h=0 c#=110 <26f051f0014eaa35>
    [B1] 0.000/70 [prior 0.078/128 amaf 0.000/213 crit 0.000 vloss 0] h=0 c#=111 <26f05730014eaf6a>
   [B1] 0.012/81 [prior 0.684/95 amaf 0.036/553 crit -0.988 vloss 0] h=0 c#=110 <26f051f1014eaa36>
    [A1] 0.015/66 [prior 0.071/140 amaf 0.014/207 crit 0.000 vloss 0] h=0 c#=111 <26f05aad014eb2dc>
   [pass] 0.000/75 [prior 0.500/20 amaf 0.000/0 crit -1.000 vloss 0] h=0 c#=111 <26f051ef014eaa34>
    [P14] 0.000/64 [prior 0.125/80 amaf 0.000/192 crit 0.000 vloss 0] h=0 c#=112 <26f058c9014eb0fe>
   [P14] 0.000/68 [prior 0.875/80 amaf 0.050/782 crit -0.456 vloss 0] h=0 c#=110 <26f0523c014eaa81>
    [O14] 0.000/57 [prior 0.069/145 amaf 0.000/177 crit 0.000 vloss 0] h=0 c#=113 <26f055b8014eadf6>
   [N14] 0.304/56 [prior 0.833/60 amaf 0.204/810 crit -0.643 vloss 0] h=0 c#=110 <26f0523a014eaa7f>
  [S4] 0.050/161 [prior 0.097/103 amaf 0.091/1688 crit -0.571 vloss 0] h=0 c#=113 <26f04cc2014ea51a>
   [O6] 0.050/60 [prior 0.949/195 amaf 0.035/254 crit -0.350 vloss 0] h=0 c#=110 <26f04d42014ea598>
 [N14] 0.941/882 [prior 0.944/178 amaf 0.730/3671 crit -0.042 vloss 0] h=0 c#=111 <26f04c86014ea4de>
  [N13] 0.950/358 [prior 0.051/198 amaf 0.956/1740 crit 0.000 vloss 0] h=0 c#=113 <26f05387014eabca>
   [F4] 0.970/237 [prior 0.923/130 amaf 0.969/797 crit -0.000 vloss 0] h=0 c#=108 <26f07286014eca71>
    [K1] 0.907/54 [prior 0.087/115 amaf 0.939/245 crit 0.101 vloss 0] h=0 c#=112 <26f07975014ed154>
   [O6] 0.911/90 [prior 0.949/195 amaf 0.938/518 crit -0.031 vloss 0] h=0 c#=109 <26f07296014eca81>
  [K15] 0.945/109 [prior 0.120/83 amaf 0.944/673 crit -0.014 vloss 0] h=0 c#=113 <26f0538d014eabd0>
   [O6] 0.927/55 [prior 0.944/180 amaf 0.930/200 crit -0.000 vloss 0] h=0 c#=109 <26f07459014ecc42>
  [J11] 0.978/89 [prior 0.303/99 amaf 0.977/393 crit 0.000 vloss 0] h=0 c#=114 <26f0537d014eabc0>
   [K16] 0.987/77 [prior 0.953/215 amaf 0.987/239 crit 0.000 vloss 0] h=0 c#=108 <26f073a4014ecb8d>
  [H10] 0.985/68 [prior 0.333/90 amaf 0.990/303 crit -0.000 vloss 0] h=0 c#=114 <26f05375014eabb8>
   [K16] 0.982/55 [prior 0.953/215 amaf 0.982/165 crit 0.000 vloss 0] h=0 c#=108 <26f074f8014ecce1>
  [K1] 0.906/64 [prior 0.133/75 amaf 0.931/788 crit 0.054 vloss 0] h=0 c#=113 <26f05346014eab89>
  [pass] 0.968/63 [prior 0.500/20 amaf 0.000/0 crit -0.032 vloss 0] h=0 c#=114 <26f05340014eab83>
 [A2] 0.010/191 [prior 0.960/248 amaf 0.341/1098 crit -0.859 vloss 0] h=0 c#=111 <26f04c45014ea49d>
  [A3] 0.011/182 [prior 0.050/200 amaf 0.011/552 crit -0.000 vloss 0] h=0 c#=112 <26f04fc9014ea819>
 [B13] 0.043/140 [prior 0.870/231 amaf 0.218/772 crit -0.829 vloss 0] h=0 c#=111 <26f04c83014ea4db>
  [B12] 0.042/118 [prior 0.035/285 amaf 0.039/383 crit 0.000 vloss 0] h=0 c#=113 <26f050e1014ea92d>
(avg score 1.495299/5010; dynkomi's 2.377203/644907 value 0.539632/645342)
*** WINNER is Q1 (16,1) with score 0.0958 (1461/5004:5004/5047 games), extra komi 0.000000
genmove in 2.45s (2061 games/s, 515 games/s/thread)
[5047] best 0.095825 xkomi 0.0 | seq  Q1  A2  O6  N8 | can b  Q1(0.096) N14(0.941)  A2(0.010) B13(0.043) 
(resign)

I start a gogui game of pachi vs pachi with:
pachi -t 60 threads=6,max_tree_size=6000
, the first surprise is that it plays rubbish moves, eg. first move is K17.

The second surprise is that it first "thinks" for 50 seconds on the first move and then instead of doing that for all other moves makes all of them at once!

Hi!

I am reading this thread: #82 (Pachi Resigns on High Handicap Games)

As I understand, for handicap games, Pachi somehow adjusts the win rates, making black and white winrates more or less equals at the beginning of the game, to avoid early resign.

Is that right? If so, I am interested to understand how the new win rates are calculated, and if there is a way to calculate back the original win rates. (because original win rates make more sense when used in goreviewpartner)

Hi!
I am adding support for Pachi in goreviewpartner, and I am curious about the meaning of the right side goban that appears in stderr following genmove command:

      A B C D E F G H J K L M N O P Q R S T        A B C D E F G H J K L M N O P Q R S T  
    +---------------------------------------+    +---------------------------------------+
 19 | . . . . . . . . . . . . . . . . . . . | 19 | x x x x x x , , , , , , x x x x X X X |
 18 | . . . . . . . . . . . . . . . . . . . | 18 | x x x x x x , , , , , , x x x x X X X |
 17 | . X X X . X . . . . . . . X . . . . . | 17 | x x x x , X , , , , , , x X x X X X X |
 16 | . X O O O . . . . . . . . . . X . X . | 16 | , x O O O , , , , , , , , , x X x X X |
 15 | . O O . . . O . . . . . . . . . . . . | 15 | o O O O O o O o , , , , , , , , , , , |
 14 | . . X . . . . . . . . O . . O . O . . | 14 | O O o o o o o o , , , o , , o , , , , |
 13 | . . O . . . . . . . . . . . . . . . . | 13 | O O O o o o , , , , , , , , , , , , , |
 12 | . . O X . . . . . . . . . . . . X . . | 12 | O O O , , , , , , , , , , , , , x , , |
 11 | . . X O . . . . . . . . . X X X . . . | 11 | O O o O o o , , , , , , , X X X , , , |
 10 | . . . . . . . . . . . . . X)O O O . . | 10 | O O O O o , , , , , , , , x O O O o , |
  9 | . . . . . . . . . . . . . . . . . . . |  9 | O O O O o o , , , , , , , , o o o o o |
  8 | . . O . . . . . . . . . . . . . . . . |  8 | O O O O o o , , , , , , , , , o o o o |
  7 | . . . . . . . . . . . . . . . . O . . |  7 | O O O O O o o , , , , , , , , , O o , |
  6 | . . X O O . . . . . . . . . . . . . . |  6 | O O O O O O , , , , , , , , , , , , , |
  5 | . . O O X O . . . . . . . . . . . . . |  5 | O O O O X O o , , , , , , , , , , , , |
  4 | . . O X X . . . . . . . . . . . X . . |  4 | , o O X X , , , , , , , , , x x X x , |
  3 | . O X O X . . . . . . . . . X . . . . |  3 | , o X X X , , , , , , , , x X x x x x |
  2 | . X X . . . . . . . . . . . . . . . . |  2 | x X X X X x , , , , , , , x x x x x x |
  1 | . . . . . . . . . . . . . . . . . . . |  1 | x X X X x x , , , , , , , x x x x x x |
    +---------------------------------------+    +---------------------------------------+

Is it an influence map? a territory map? or something else?

Is it possible that dcnn "forces" Pachi sometimes to play moves that loose tactically?

I'd like to draw your attention to this game after White's move 151. b11. Pachi plays black and is to move. It is Pachi version is 11.99, with dcnn support, updated on Sept. 10th, which I think is still the latest version.

The thing is that Pachi with black plays 152. b14? to atari and capture one stone on the second line, as strongly suggested by dcnn, but this moves seems to loose the fight on the spot. My understanding of this position is that instead 152. a12! is correct, winning the capturing race, and black can resign.

It is interesting to study the ~6 black moves before that position. Black 134. d14 is a severe attack, and Pachi seems to work confidently towards the position after W151, "knowing" he can win it with 152. a12 (as suggested by it's winning probability of ~65%). But then dcnn kicks in, prevents the correct follow-up move 152. a12 and replaces it with a "good shape move" 152. b14 which is correct in 98% of such positions, but fails in this one.

Is my analysis correct?

Thanks, Peter

(;FF[4]CA[UTF-8]AP[GoGui:1.4.9]
HA[2]PB[Pachi 11.99 on auriga]PW[CrazyPhone 5dan Slow]DT[2016-11-10]
RE[W+Resign]
AB[dp][pd]PL[W];W[];B[pp];W[dd];B[fc];W[cf];B[jd];W[qf];B[qh];W[qc];B[qd]
;W[pc];B[od];W[rd];B[re];W[rc];B[qe];W[nc];B[jp];W[qn];B[qk]
;W[qq];B[qp];W[pq];B[op];W[rp];B[ro];W[rq];B[qo];W[nq];B[np]
;W[mq];B[ck];W[lo];B[ch];W[db];B[mn];W[fq];B[eq];W[fp];B[jn]
;W[do];B[co];W[eo];B[cn];W[cq];B[cp];W[er];B[km];W[nd];B[ne]
;W[me];B[mf];W[nf];B[oe];W[le];B[ng];W[lf];B[mg];W[hc];B[hd]
;W[ic];B[id];W[gc];B[gd];W[fb];B[ec];W[eb];B[ig];W[lg];B[lh]
;W[kh];B[li];W[ki];B[kg];W[lj];B[oc];W[ob];B[nb];W[mb];B[md]
;W[mc];B[pb];W[na];B[kf];W[ld];B[kj];W[jj];B[kk];W[ii];B[hh]
;W[gj];B[jh];W[ji];B[mj];W[fh];B[ff];W[gg];B[gf];W[hg];B[ih]
;W[hf];B[if];W[eg];B[gi];W[fi];B[hj];W[hk];B[fj];W[gk];B[ik]
;W[ej];B[bq];W[dq];B[cr];W[dr];B[gh];W[fg];B[fk];W[fl];B[ek]
;W[dk];B[el];W[dl];B[em];W[cj];B[dm];W[cl];B[oq];W[or];B[pr]
;W[nr];B[ei];W[dj];B[df];W[dg];B[cg];W[ef];B[de];W[ce];B[ee]
;W[fe];B[ed];W[ge];B[fd];W[cd];B[dh];W[eh];B[di];W[bg];B[bh]
;W[bi]
C[Black A looks obvious, but looses the fight instantly.

Black B seems to win on the spot.]
(;B[bf]C[error due to dcnn?];W[ah];B[ag];W[ai];B[be];W[ci];B[bg];W[bd];B[gn];
W[br]
;B[ar];W[cs];B[mp];W[lp];B[kq];W[lq];B[bs];W[as];B[hq];W[hp]
;B[bs];W[iq];B[ir];W[ip];B[jq];W[hr];B[gr];W[gq];B[io];W[ln]
;B[lm];W[mo];B[nn];W[no];B[oo];W[rn];B[pn];W[so];B[sp];W[sn]
;B[qm];W[as];B[sm];W[sq];B[rm];W[jc];B[hs];W[jr];B[kr];W[is]
;B[qr];W[rr];B[sp];W[so];B[fo];W[ep];B[bs];W[cr];B[bm];W[se]
;B[rf];W[sf];B[sg];W[sd];B[rb];W[qb];B[qa];W[pa];B[he];W[ae]
;B[bl];W[rg];B[qg];W[sh];B[rh];W[sg];B[dc];W[cc];B[kd];W[kc]
;B[si];W[ke];B[je];W[fn];B[go];W[en];B[fm];W[ho];B[hn];W[ko]
;B[jo];W[bk];B[js];W[ks];B[ls];W[lr];B[js];W[ir];B[gp];W[hq]
;B[ms];W[ns];B[ks];W[bp];B[ap];W[aq];B[ps];W[ao])
(;B[ah]C[... and B wins.];W[ci];B[bf];W[ai];B[ag];W[ae];B[be];W[ad];B[bd];
W[bc]
;B[he]))

running make MAC=1 throws below error:

random.c:74:69: error: expected ';' at end of declaration
        unsigned long pmseed = (unsigned long)pthread_getspecific(seed_key)
                                                                           ^
                                                                           ;
1 error generated.

Adding back the semicolon fixed the issue.

diff --git a/t-unit/sar.t b/t-unit/sar.t
index f003418..6b32fb8 100644
--- a/t-unit/sar.t
+++ b/t-unit/sar.t
@@ -231,6 +231,19 @@ XXXX
sar w c3 0
sar w c2 1

+% Eyeshape-avoidance nakade 3
+boardsize 6
+XXXXXX
+XXXXXX
+XXXXXX
+XXXXXX
+X..OOX
+XXXXXX
+sar w c2 0
+sar w B2 1
+sar b c2 0
+sar b B2 1
+
% False nakade
boardsize 5
X.XX.

Linux all error:
"make: *** No rule to make target .git/HEAD', needed by build.h'. Stop."

Hi,

I noticed Pachi resigns 9 stones handicap games as white.
Looks like passing dynkomi=linear:handicap_value=8%8 fixes it,
Shouldn't it be the default ?

I got NVIDIA CUDA 9.0 + cuDNN + tensorflow etc up and running (for Leela_Zero) but never managed to get Caffe up and running so I thought about going with Docker's NVIDIA and Caffe containers for Pachi.

Before I start to build all that, can Pachi be built/use Docker containers?
If so, perhaps you can give me few pointers how to get it up an running. My experience with Docker is rather limited.

It would be nice if you gave a few examples of time setup command line usage.

Hello, not sure if this an issue or pull request, here I go:
First, thanks for making this project open source, not only that,
it is beautifully documented.

I am trying to run pachi in a javascript environment using emscripten.
Compilation is OK, but thread related functions are not defined.

If I understand correctly, the only workaround is modifying the source code
and avoid threads.

I would like to invest my time on this; do you think is possible?,
do you have any recommendation?.

Thanks and again; awesome project!.

[1000] best 50.9% xkomi 7.4 | seq E16 J3 R16 Q4 | can w D16(51.1) E16(50.7) C17(51.3) F17(50.9) Assertion failed! Program: C:\bin\pachi\pachi19x19_x64.exe File: search.c, Line 431 Expression: !(ti->dim == TD_GAMES && ti->len.games < GJ_MINGAMES) C:\bin\pachi>

Command line:
C:\bin\pachi>pachi19x19_x64.exe -t =10

Version 12.00
git 1586655

Hi,

the following sequence of GTP commands crashes pachi (master):

/usr/local/bin/pachi -d3 --nodcnn -t =40000 -f book.dat threads=4,maximize_score

boardsize 9
set_free_handicap C3 G7 C7
komi 0
genmove w

pachi: ../board.h:629: board_get_atari_neighbor: Assertion `coord != pass' failed.

with the following command line I get a segfault:

/usr/local/bin/pachi -d3 --nodcnn -t 10 -f book.dat threads=4,maximize_score

Thread 7 "pachi" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffb2dac700 (LWP 10855)]
0x00005555555a9c3e in ?? ()
(gdb) bt
#0  0x00005555555a9c3e in ?? ()
#1  0x00005555555856d0 in playout_play_move ()
#2  0x0000555555585926 in playout_play_game ()
#3  0x000055555558c595 in uct_mcowner_playouts ()
#4  0x0000555555591543 in ?? ()
#5  0x00007ffff652f494 in start_thread (arg=0x7fffb2dac700)
at pthread_create.c:333
#6  0x00007ffff6271acf in clone ()

Is machine learning/deep learning, etc. (things described to be in Alphago) going to be attempted to be implemented in pachi? Would it make sense to add this into the TODO list?

Is there a tutorial for newbie or some tip specific to run pachi dcnn ? Im using archlinux armv7h

Hey,

I haven't had an opportunity to ask few of these:

• Is the comment about cache misses in node.h still relevant? Does it make sense to implement a tagged allocator or some other per-thread page allocator? Is there some lower or upper bound heuristic for the node count?
• Can the self-eye-fill code be simplified, e.g. replaced with a pattern database that compiles to C code? It's really ugly and complicated.
• Do the DCNN changes regress the non-DCNN version, with DCNN disabled?
• How is DCNN compared to AlphaGo in a best-case scenario (unlimited tensor units)? The DCNN code was developed prior to DeepMind papers so does it use a different technique?
• Is pondering still disabled with DCNN?
• @lemonsqueeze are you the current maintainer?

(edited since initial posting)

Hi,

Recently, I started to notice this issue, and it's happens quite a lot during game analysis (until now, I had not really tried to catch the stderr message, thinking it was more a GRP issue, so I did not know what was causing this issue). What does that means?

I encounter that when analysing games moves by moves, after each move, I clear_board, then replay the entire game before asking for a genmove. Then sometime (in the example below, after 200 moves) Pachi just crashes :(

IN: clear_board
IN: komi 0.5
IN: set_free_handicap D4 Q4 K10 D16 Q16
Move:   5  Komi: 0.5  Handicap: 5  Captures B: 0 W: 0
A B C D E F G H J K L M N O P Q R S T
+---------------------------------------+
19 | . . . . . . . . . . . . . . . . . . . |
18 | . . . . . . . . . . . . . . . . . . . |
17 | . . . . . . . . . . . . . . . . . . . |
16 | . . . X . . . . . . . . . . . X). . . |
15 | . . . . . . . . . . . . . . . . . . . |
14 | . . . . . . . . . . . . . . . . . . . |
13 | . . . . . . . . . . . . . . . . . . . |
12 | . . . . . . . . . . . . . . . . . . . |
11 | . . . . . . . . . . . . . . . . . . . |
10 | . . . . . . . . . X . . . . . . . . . |
9 | . . . . . . . . . . . . . . . . . . . |
8 | . . . . . . . . . . . . . . . . . . . |
7 | . . . . . . . . . . . . . . . . . . . |
6 | . . . . . . . . . . . . . . . . . . . |
5 | . . . . . . . . . . . . . . . . . . . |
4 | . . . X . . . . . . . . . . . X . . . |
3 | . . . . . . . . . . . . . . . . . . . |
2 | . . . . . . . . . . . . . . . . . . . |
1 | . . . . . . . . . . . . . . . . . . . |
+---------------------------------------+

IN: play white O3
IN: play black R6
IN: play white R10
IN: play black R14
IN: play white F3
IN: play black C6
IN: play white R3
IN: play black Q3
IN: play white R4
IN: play black R5
IN: play white Q2
IN: play black P2
IN: play white Q1
IN: play black P3
IN: play white O2
IN: play black P1
IN: play white S2
IN: play black O4
IN: play white N4
IN: play black O5
IN: play white N5
IN: play black O6
IN: play white L3
IN: play black N6
IN: play white M6
IN: play black R8
IN: play white R9
IN: play black N8
IN: play white Q8
IN: play black R7
IN: play white P7
IN: play black P6
IN: play white P9
IN: play black R12
IN: play white S11
IN: play black S12
IN: play white S8
IN: play black S7
IN: play white T8
IN: play black T7
IN: play white S10
IN: play black P11
IN: play white O10
IN: play black O11
IN: play white N10
IN: play black M7
IN: play white L6
IN: play black L7
IN: play white Q13
IN: play black Q14
IN: play white R17
IN: play black Q17
IN: play white R18
IN: play black R16
IN: play white S16
IN: play black S15
IN: play white T16
IN: play black T15
IN: play white S18
IN: play black Q18
IN: play white T17
IN: play black M17
IN: play white P18
IN: play black Q19
IN: play white N17
IN: play black N16
IN: play white F17
IN: play black J17
IN: play white P13
IN: play black O14
IN: play white O13
IN: play black N11
IN: play white P14
IN: play black P15
IN: play white M9
IN: play black L9
IN: play white N14
IN: play black O15
IN: play white M13
IN: play black M10
IN: play white M11
IN: play black L10
IN: play white Q11
IN: play black M12
IN: play white Q12
IN: play black L11
IN: play white N12
IN: play black L13
IN: play white L14
IN: play black M15
IN: play white M14
IN: play black K13
IN: play white K15
IN: play black M16
IN: play white K17
IN: play black K18
IN: play white H17
IN: play black K16
IN: play white J16
IN: play black L17
IN: play white H15
IN: play black K14
IN: play white L15
IN: play black F15
IN: play white C14
IN: play black C17
IN: play white C11
IN: play black C9
IN: play white F13
IN: play black E11
IN: play white B16
IN: play black B17
IN: play white E14
IN: play black D12
IN: play white C12
IN: play black D13
IN: play white D14
IN: play black E17
IN: play white F16
IN: play black F18
IN: play white E15
IN: play black G17
IN: play white G16
IN: play black H18
IN: play white G18
IN: play black E18
IN: play white D10
IN: play black E10
IN: play white D9
IN: play black C8
IN: play white D8
IN: play black D7
IN: play white F8
IN: play black G10
IN: play white H9
IN: play black H10
IN: play white D2
IN: play black C2
IN: play white D3
IN: play black C3
IN: play white E4
IN: play black D5
IN: play white E7
IN: play black E6
IN: play white F6
IN: play black K6
IN: play white K5
IN: play black J6
IN: play white J5
IN: play black H14
IN: play white G14
IN: play black H12
IN: play white H13
IN: play black J14
IN: play white G12
IN: play black J15
IN: play white P10
IN: play black O8
IN: play white H16
IN: play black J12
IN: play white H6
IN: play black J9
IN: play white J7
IN: play black K7
IN: play white J8
IN: play black G9
IN: play white H8
IN: play black G8
IN: play white H7
IN: play black G7
IN: play white F7
IN: play black G6
IN: play white G5
IN: play black F9
IN: play white E5
IN: play black E9
IN: play white E8
IN: play black C10
IN: play white D11
IN: play black E12
IN: play white K8
IN: play black L8
IN: play white H19
IN: play black J18
IN: play white B10
IN: play black C15
IN: play white B15
IN: play black E16
IN: play white D15
IN: play black D18
IN: play white B7
IN: play black C7
IN: play white A8
IN: play black B6
IN: play white B9
IN: play black T4
IN: play white T3
IN: play black S4
IN: play white R1
IN: genmove black
Move:  206  Komi: 0.5  Handicap: 5  Captures B: 2 W: 1
 A B C D E F G H J K L M N O P Q R S T        A B C D E F G H J K L M N O P Q R S T
   +---------------------------------------+    +---------------------------------------+
19 | . . . . . . . O . . . . . . . X . . . | 19 | : : : : : : : : : : : : : : : : : : : |
18 | . . . X X X O X X X . . . . O X O O . | 18 | : : : : : : : : : : : : : : : : : : : |
17 | . X X . X O . O X . X X O . . X O . O | 17 | : : : : : : : : : : : : : : : : : : : |
16 | . O . X X O O O O X . X X . . X X O O | 16 | : : : : : : : : : : : : : : : : : : : |
15 | . O X O O X . O X O O X . X X . . X X | 15 | : : : : : : : : : : : : : : : : : : : |
14 | . . O O O . O X X X O O O X O X X . . | 14 | : : : : : : : : : : : : : : : : : : : |
13 | . . . X . O . O . X X O . O O O . . . | 13 | : : : : : : : : : : : : : : : : : : : |
12 | . . O X X . O X X . . X O . . O X X . | 12 | : : : : : : : : : : : : : : : : : : : |
11 | . . O O X . . . . . X . X X X O . O . | 11 | : : : : : : : : : : : : : : : : : : : |
10 | . O X O X . X X . X X X O O O . O O . | 10 | : : : : : : : : : : : : : : : : : : : |
 9 | . O X O X X X O X . X O . . O . O . . |  9 | : : : : : : : : : : : : : : : : : : : |
 8 | O . X O O O X O O O X . X X . O X O O |  8 | : : : : : : : : : : : : : : : : : : : |
 7 | . O X X O O X O O X X X . . O . X X X |  7 | : : : : : : : : : : : : : : : : : : : |
 6 | . X X . X O X O X X O O X X X . X . . |  6 | : : : : : : : : : : : : : : : : : : : |
 5 | . . . X O . O . O O . . O X . . X X . |  5 | : : : : : : : : : : : : : : : : : : : |
 4 | . . . X O . . . . . . . O X . X O X X |  4 | : : : : : : : : : : : : : : : : : : : |
 3 | . . X O . O . . . . O . . O X X O O O |  3 | : : : : : : : : : : : : : : : : : : : |
 2 | . . X O . . . . . . . . . O X O . O . |  2 | : : : : : : : : : : : : : : : : : : : |
 1 | . . . . . . . . . . . . . . X O O). . |  1 | : : : : : : : : : : : : : : : : : : : |
   +---------------------------------------+    +---------------------------------------+
mcowner 0.08s
dcnn in 0.27s
no gamma for feature (mcowner:9) !

I just wish to use pachi cpu version under mac OS.
So first I install:
brew install openblas
export LDFLAGS="-L/usr/local/opt/openblas/lib"
export CPPFLAGS="-I/usr/local/opt/openblas/include"
and then modified Makefile.mac
SYS_LIBS := -lm -lrt -ldl

Use this command line to build
make MAC=1 DCNN=0, but got

What scoring method does Pachi use?

I was testing it against Gnu Go 3.8, and Pachi lost by 0.5 point using the Japanese rules. However, if Pachi is internally using, say, the AGA rules, then it should consider that it instead wins by 0.5 points (white pass stone given to him).

So, it would be nice to document what scoring method Pachi use in the GitHub README, or even better to have options to change the method (I am thinking of the free Mac app Goban, which forces users to use Japanese scoring).

Hi,

Kindly, I would like to know if there is anyone here who could tell me some information related to Pachi.

What I need is to know important matches between Pachi and Humans since 2008. Also, for these matches I'm looking for the hardware and algorithm (if was used or not NNs) description used in these matches.

So can you help me to fill up this table?

Also, if anybody here knows what was the hardware used by Pachi on the 2016 WCCI (http://oase.nutn.edu.tw/WCCI2016/result.htm) and if it was using neural networks please, let me know!

Many thanks!

Hi,

I was seeing strange results while testing the new selfatari code, no matter what I tried it didn't seem to make a difference in playing strength. At first i thought the new code might not be that good after all but then i tried an improved version and still no difference !

I was going to try to use it only in the prior code which surely should be beneficial when i noticed playout_moggy_assess_one() does:

if (!board_playing_ko_threat && is_bad_selfatari)
    add_prior_value(0)

Shouldn't it be something like this ?

if (!board_playing_ko_threat && is_selfatari)
    if (is_bad_selfatari)
        add_prior_value(0)
    else
        add_prior_value(1)

Just tried a few games with this, looks like winrates improve quite a bit.

I was wondering about the selfatari logic in patterns.c also, does this mean there are two selfatari prior inputs ?

pachi_gtp.txt

I ran it with:
pachi -t =120 threads=6,max_tree_size=5000

same thing with:
pachi -t =30 threads=8,max_tree_size=3072
!!!

lz-genmove_analyze support (get winrates in sabaki etc)
lz-analyze: handle frequency

How does this work?

window 10 error!

Pachi version 12.20 (Jowa)
git d0bc743 (master)
x86-64 dcnn build, Nov 4 2018 [19x19]

Random seed: 1541508186
Loading opening fbook book.dat...
Loaded Detlef's 54% dcnn for 19x19
Assertion failed!

Program: C:\baduk\pachi\pachi19x19_x64.exe
File: patternsp.c, Line 377

Expression: id == index

Tarballs downloaded from github don't have the .git directory.
This lookup should be made optional.

Hi.

I am reading your code related with joseki.

I wonder if there should be negative of board_is_valid_play in joseki_check function.
Currently it seems the function puts invalid plays in move_queue.

Hi there,

I just installed pachi 11.99 with book.dat, patterns, and dcnn support. I am running it on a 24-core Linux machine. It's a great program, too strong for me, I enjoy playing it a lot!

The game below demonstrates, however, that pachi (W) seems to have a some problem with seki. Around move #135, pachi engaged into a "killing variation" that would have decided the game, if it worked. But the truth is, it's only seki, very basic one, so B was alive. Pachi didn't stop playing and was still claiming to win until the very end ...

When I tried programming go myself, this was one of the basic problems that I couldn't solve. During play-outs, when to stop filling in stones, and when to continue. Some go knowledge seems to be necessary. Pachi seems not to try continuing in this case.

Maybe, the position around move #135 is a good test case.

Thanks for pachi. Peter

(;FF[4]CA[UTF-8]AP[GoGui:1.4.9]
HA[4]PB[pw31]PW[Pachi 11.99 on auriga 24 cores]DT[2016-04-30]RE[B+33]
AB[dp][pd][dd][pp]PL[W];W[qf];B[qh];W[of];B[nd];W[pi];B[ph];W[oh];B[qi];W[pj];
B[qj]
;W[pk];B[ql];W[om];B[qn];W[lc];B[ld];W[kd];B[le];W[mc];B[nc]
;W[md];B[me];W[ne];B[kc];W[kb];B[jc];W[jb];B[ic];W[nb];B[ob]
;W[ib];B[hc];W[hb];B[gc];W[cj];B[ce];W[mb];B[gb];W[cn];B[fq]
;W[rd];B[bp];W[en];B[bn];W[co];B[bo];W[cp];B[cq];W[cm];B[bm]
;W[cl];B[mg];W[ng];B[mh];W[qc];B[nh];W[og];B[oe];W[nf];B[pc]
;W[mf];B[lf];W[lg];B[je];W[kg];B[jf];W[li];B[ih];W[qb];B[nj]
;W[oi];B[lj];W[kj];B[lk];W[kk];B[ch];W[ll];B[kl];W[jl];B[km]
;W[ml];B[jm];W[il];B[im];W[hl];B[hm];W[gl];B[fo];W[nq];B[lq]
;W[pq];B[qq];W[qr];B[oq];W[pr];B[or];W[op];B[nr];W[np];B[mq]
;W[qp];B[po];W[rp];B[nn];W[mn];B[mo];W[ln];B[ko];W[kn];B[jo]
;W[jn];B[io];W[dh];B[cg];W[gh];B[di];W[ci];B[eh];W[dj];B[ei]
;W[gj];B[gg];W[rm];B[rl];W[qm];B[pl];W[pm];B[qk];W[rg];B[ol]
;W[nm];B[rh];W[ni];B[rj];W[si];B[sh];W[sk];B[sl];W[sj];B[qg]
;W[re];B[pf];W[pg];B[pe];W[mj];B[no];W[rf];B[rn];W[sm];B[ej]
;W[ek];B[fk];W[fl];B[el];W[dk];B[fm];W[em];B[fn];W[bh];B[bl]
;W[bg];B[bf];W[dg];B[cf];W[eg];B[fg];W[fh];B[ef];W[fj];B[df]
;W[ga];B[fa];W[ha];B[fb];W[pn];B[qo];W[sn];B[oo];W[rr];B[bk]
;W[hh];B[bj];W[bi];B[hg];W[in];B[hn];W[eo];B[ep];W[lo];B[lp]
;W[jg];B[ig];W[kf];B[ke];W[la];B[ii];W[gm];B[sg];W[gn];B[go]
;W[lm];B[ho];W[mi];B[sf];W[pb];B[se];W[sd];B[oc];W[oa];B[ai]
;W[ij];B[ag];W[ah];B[af];W[aj];B[ak];W[ji];B[ai];W[nk];B[nl]
;W[ro];B[ok];W[do];B[oj];W[mk];B[jh];W[kh];B[fi];W[gi];B[hj]
;W[hk];B[hi];W[gk];B[jk];W[os];B[ns];W[ps];B[lr];W[qd];B[bq]
;W[qe];B[aj];W[ck];B[ec];W[od];B[mp];W[mm];B[on];W[lh];B[]
;W[dl];B[];W[so];B[];W[jj];B[];W[sr];B[];W[ik];B[]
;W[lk];B[];W[oe];B[];W[ma];B[];W[pd];B[];W[lj]
C[W doesn't stop playing ...
W simply doesn't understand the seki on the right hand side]
)

Pachi has trouble with seki, because Pachi has buggy selfatari detection and possibly the nakade code.

Seki would be solved by just setting selfatarirate=100 or =99 in Moggy and debugging the playouts in lost positions, there ought to be just some bug there that prevents things to go correctly.

The issue's with the WIN macro. There's no homogenous Windows build target, e.g. one that has or has no <regex.h>.

Note that, for instance, CMake doesn't define WIN32 on Cygwin. Cygwin's not Win, it's Unix. It is POSIX.

OTOH, mingw-w64 is WIN32. It's a compat wrapper to build the GNU toolchain and some simple, short headers for missing POSIX functionality.

Fix the confusion with WIN Makefile stuff, seeing here choices:

• treat as WIN32_NO_POSIX, remove "#include <regex.h>" and so forth which isn't in C89 but POSIX only. Remove confusing text about performance issues.
• add another macro for mingw variants, so that it builds
• pretend problem doesn't exist

See also forthcoming pull request.

uct/internal.h defines max_tree_size as following:

unsigned long max_tree_size;

While on 64-bit Linux unsigned long is 64 bit wide, the standard requires it to be at least 32 bit; and indeed, on some 64-bit platforms (Windows: Visual C or mingw64 in msys2 environment) it's 32 bit only. As a result, the max_tree_size setting, provided in command line, will be taken modulo 4 Gb. In other words, if 64-bit pachi is run with max_tree_size being 4 Gb, it is effectively running with max_tree_size being 0.

The proper fix would be to define max_tree_size as size_t (max_tree_size is passed to malloc2, which is a #define for checked_malloc, which expects size_t).

I don't have a proper understanding of the pachi's code to make a patch immediately; at the first look just changing max_tree_size type opens Pandora box, as there seems to be other stuff which has to be of the same type. And using -Wconversion for the compiler does not help because it produces a zillion of warnings even without this change.

I'll see what I can do, though.

in dcnn.cpp, function dcnn_get_moves, I find board->b is NULL.

But in uct/prior.c, function uct_prior_dcnn, I find map->b->b is NOT NULL.

This is strange, is it because of thread-safety?

Hey,

Responding to @pasky's earlier request for work regarding struct tree_node cache locality.

The issue is not completely trivial, particularly due to threading and the arbitrary order in which nodes are traversed. This is not merely refactoring.

My best idea is to allocate pages, or several, on a per-thread basis. Get rid of sibling pointer, next sibling can be calculated by parent plus pointer arithmetic of parent->data with regard to given struct tree_node's address. There probably needs to be stored the thread's id as well as a reference count in the page's end or beginning.

Some questions remain, most importantly - can multiple threads add subnodes to the same node?

Another idea is to realloc(3) node's data keeping excess free capacity. But threading again.

Thanks.

This seems very similar to issue 54.

Till a couple months ago I was able to compile the DCNN version of pachi, but it doesn't work anymore.

On my system, caffe.hpp is located at /opt/caffe/include/caffe/caffe.hpp, and I set CAFFE_PREFIX of Makefile as /opt/caffe/include/ or similar variants.

The make command gives place to:

[CXX] dcnn.cpp
dcnn.cpp:13:27: fatal error: caffe/caffe.hpp: No such file or directory
#include <caffe/caffe.hpp>
^
compilation terminated.
make: *** [Makefile.lib:78: dcnn.o] Error 1

caffe is compiled and files are in:

/something/PACHI_GO_ENGINE/caffe/distribute/include/caffe/caffe.hpp
/something/PACHI_GO_ENGINE/caffe/include/caffe/caffe.hpp

compiling pachi in:

/something/PACHI_GO_ENGINE/pachi/

I updated the Makefile :

DCNN=1
#CAFFE_LIB=/usr/local/lib
CAFFE_LIB=/something/PACHI_GO_ENGINE/caffe/include  #(and few other versions of this)

and I still get dcnn.cpp:13:27: fatal error: caffe/caffe.hpp: No such file or directory

[CC]   fbook.c
[CC]   chat.c
[CXX]   dcnn.cpp
dcnn.cpp:13:27: fatal error: caffe/caffe.hpp: No such file or directory
compilation terminated.
Makefile.lib:78: recipe for target 'dcnn.o' failed
make: *** [dcnn.o] Error 1

It seems that pachi has no idea when to stop playing.
For example, I used:

-f book.dat -t _1200 -e dcnn -t =5000:15000 threads=4,max_tree_size=3072

adding maximize_score had no positive effect.

Opponent keeps passing while pachi fills up his own eyes and then loses the game.

This is true for Pachi in both greedy and normal mode, but not for the DCNN (which does not know when to resign at all). Resigning on a lost game is the desired behaviour, but not on a handicap game. Is it possible to workaround this?

Greetings.
I have a problem with the "write pipe" function in UE4.
I read the data from the "readPipe" without any problems. But when I try to send data "genmove b" through "writePipe", I get the same in the response in "readPipe".

1. I create a process
   FProcHandle ProcessHandle = FPlatformProcess::CreateProc(tFilename, tArguments, false, false, false, NULL, 0, tWorkingDirectory, goWritePipe, goReadPipe);
2. i wait 2 seconds
3. Read from ReadPipe
   FString myOut = FPlatformProcess::ReadPipe(goReadPipe);
   I get all the initial information
4. I wait 2 seconds
5. I send a "genmove b" to the WritePipe
   if (FPlatformProcess::WritePipe(goWritePipe, "genmove b"))
6. I wait 5 seconds and try ReadPipe. And I get "genmove b".
7. But if I enter "genmove b" in the console of my process, I get all correct informations.

Could you give me any advice?

Hello,

Did anyone succeed with building under MacOSX?
I have installed Caffe and openblas with brew, executed:

export LDFLAGS="-L/usr/local/opt/openblas/lib"
export CPPFLAGS="-I/usr/local/opt/openblas/include"

in order to allow the compiler to find openblas, but I am still getting the error:

In file included from caffe.cpp:12:
In file included from /usr/local/include/caffe/caffe.hpp:9:
In file included from /usr/local/include/caffe/filler.hpp:13:
In file included from /usr/local/include/caffe/util/math_functions.hpp:11:
/usr/local/include/caffe/util/mkl_alternate.hpp:14:10: fatal error: 'cblas.h'
      file not found
#include <cblas.h>
         ^~~~~~~~~
1 error generated.

Any hints on that?

connection failed
Pachi 12.40 (Jowa)
git a372ddf (master)
x86-64 dcnn build, Apr 4 2019 [19x19]
Random seed: 1554492625
F0406 03:42:57.572049 3692 layer_factory.hpp:81] Check failed: registry.count(type) == 1 (0 vs. 1) Unknown layer type: InnerProduct (known types: Convolution, Flatten, Input, ReLU, Reshape, Softmax)
*** Check failure stack trace: ***
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000
@ 0000000000000000

option : --dcnn=detlef44 -t 5 resign_threshold=0.25

This is not a model. model is detlef44..

hey welcome to github,
how painful was that?

could not find link to email forum here, homepage, other repository, google etc,
am on strange box ~5.29Gb download, so excuse me.

did you try
sudo apt-get install pachi
it would be nice to have a debian maintainer.

am planning to set pachi up on 8 core dedicated box,
big.little architecture so don't get too excited...

be in touch

~:"

Right now for MM patterns used in tree search we do one pass looking for local patterns, and if nothing big matches another one ignoring distance this time to find good tenuki moves. The LOW_PATTERN_RATING threshold was chosen low enough that patterns' prediction rate (t-predict) isn't affected but there's probably plenty of room for increasing it. Looking at Pachi nodcnn games with human players it often tends to play too much locally, continuing even though it's hopeless (opponent breaking through with tons of cutting points ...)

If someone has computing resources to spare, play-testing with different LOW_PATTERN_RATING values might yield better style / winrate. Could use CLOP games to find the best value too.

#define LOW_PATTERN_RATING 6.0

floating_t
pattern_rate_moves(struct pattern_config *pc, struct board *b, enum stone color,
                   struct pattern *pats, floating_t *probs, struct ownermap *ownermap)
{
        /* Try local moves first. */
        floating_t max = pattern_max_rating(pc, b, color, pats, probs, ownermap, true);

        /* Nothing big matches ? Try again ignoring distance so we get good tenuki moves. */
        if (max < LOW_PATTERN_RATING)
                max = pattern_max_rating(pc, b, color, pats, probs, ownermap, false);

        return rescale_probs(b, probs, max);
}

OS:
OpenSUSE Tumbleweed

Non-default compile parameters:
Makefile -
DOUBLE_FLOATING=1
PREFIX ?= /usr
build.h: Makefile
patternsp.h -
#define spatial_hash_bits 30

The engine used only 1 core during thinking (with --nodcnn too and on pondering too) regardless of given (and rightly repeated on engine loading output) threads parameter value, while binary version (pachi-12.40-amd64) used given number of cores.
But in sparring with itself compiled engine (only on white side) used given number (2) of cores (but used half the amount of memory: 4 GiB instead of 8 GiB after loading before game starting, while version compiled without using DCNN on OpenSUSE 12.3 always used given number of cores and 8 GiB of memory on start up)...

Is it possible to compile Pachi with DCNN from source so that this engine will use cores, how it uses pachi-12.40-amd64?
Thanks in advance.

P.S. All compiled versions (on all systems) launched without "make install".

Android hackers wanted !

There's already a Pachi Android app, unfortunately it uses an old Pachi version without patterns / dcnn so it's really weak. I'd be nice to have an up-to-date version with dcnn support.

On old phones you can hack around by replacing pachi binary after installing the apk and adding data files. I've had success using armv7 static binaries from the linux release, but apparently this doesn't work on newer phones: selinux rules are more strict and a ndk build is needed.

Todo:

ndk pachi build
The big one, could split it into another issue.
nodcnn build should be easy. dcnn build needs caffe as well as all its dependencies built under ndk. Will likely run into similar issues as the windows build, which is documented (ask me). Could go for dynamic build and package the libs instead of static build, easier.

Package Pachi data files into the app
App extracts pachi binary from resources and installs it on first run. Would need to do the same (or find better packaging method) for data files as well.

Add/update strength settings ?
Right now strength levels translate to thinking time, which is device dependent. Would be nice to have a dcnn/nodcnn toggle and have levels use playouts instead of time so strength stays the same everywhere. Maybe also an option to specify pachi command line to use instead of using levels (developer mode ?).