[Computer-go] Pachi on 6x6 with long thinking time

Petr Baudis pasky at ucw.cz
Sat Jul 23 10:39:26 PDT 2011


  Hi!

On Sat, Jul 16, 2011 at 12:35:29PM -0400, Michael Williams wrote:
> >
> >  Neat! Ok, after 12 hours I agree that opening book is a must on 7x7.
> > :-)
> >
> 
> 
> Even on 6x6, Pachi cannot find the optimal 5th move (komi=3.5).
> 
> I used the command line:
> 
>      ../pachi -t =100000000 threads=3,max_tree_size=2048
> 
> That's 100 million playouts.  It likes to play the A5 or B5, which I thnk
> both lose.
> 
>       A B C D E F
>     +-------------+
>   6 | . . . . . . |
>   5 | . X). . . . |
>   4 | . . X X . . |
>   3 | . . O O . . |
>   2 | . . . . . . |
>   1 | . . . . . . |
>     +-------------+

  Exactly what Pachi output have you seen? I think you did not even
approach 100 million playouts. Pachi is not quite optimized for very
long thinking times since noone has probably so far used it this way.
This means two things:

  (i) When Pachi runs out of memory, it stops the search. (Searching
without growing the tree further is extremely harmful and noone
implemented online pruning yet.) Here, this happens after 2.1 million
playouts with max_tree_size=2048.

  (ii) You will likely hit bugs. Here, I got:

> [2100000] best 0.348237 | seq  B4  E4  E5  E3 | can  B4(0.348)  E4(0.279)  B3(0.280)  E3(0.280)
> memory limit hit (1717986952 > 1717986919)
> (UCT tree; root white; extra komi 0.000000; max depth 56)
> [pass] 0.497/100000002 [prior 0.000/0 amaf 0.000/0 crit -0.503] h=0 c#=33 <f424c>
>  [C5] 0.505/92187953 [prior 0.500/14 amaf 0.498/98964154 crit 0.023] h=0 c#=0 <f4266>
>  [B4] 0.357/6749905 [prior 0.750/28 amaf 0.434/11880881 crit 0.056] h=0 c#=32 <f4261>
>   [E4] 0.356/6743836 [prior 0.125/56 amaf 0.357/6754564 crit 0.194] h=0 c#=31 <f42a2>
>    [E5] 0.358/6685595 [prior 0.875/56 amaf 0.358/6716561 crit 0.029] h=0 c#=30 <f4304>
>     [E3] 0.357/6675537 [prior 0.167/42 amaf 0.357/6691402 crit 0.199] h=0 c#=29 <f4394>
>      [B2] 0.359/6636748 [prior 0.750/28 amaf 0.358/6664036 crit 0.103] h=0 c#=28 <f4c76>
>       [B3] 0.358/6628703 [prior 0.125/56 amaf 0.358/6644489 crit 0.197] h=0 c#=27 <154f73>
>        [A3] 0.359/6611575 [prior 0.875/56 amaf 0.359/6629284 crit 0.135] h=0 c#=26 <154fac>
>         [A2] 0.361/6268480 [prior 0.125/56 amaf 0.358/6503210 crit 0.291] h=0 c#=25 <154fc2>
>          [C6] 0.364/5076234 [prior 0.500/14 amaf 0.365/5634960 crit 0.017] h=0 c#=0 <1550af>
>          [A1] 0.346/1169089 [prior 0.938/112 amaf 0.478/4317305 crit 0.041] h=0 c#=24 <15509b>
>           [F5] 0.343/1160392 [prior 0.250/28 amaf 0.344/1165783 crit 0.149] h=0 c#=24 <155684>
>            [C2] 0.359/1007350 [prior 0.750/28 amaf 0.359/1012680 crit 0.145] h=0 c#=22 <156267>
> (avg score 0.000000/0 value 0.000000/0)
> [100044550] best 0.505099 | seq  C5             | can  C5(0.505)  B4(0.357)  E4(0.279)  B3(0.280)
> *** WINNER is C5 (3,5) with score 0.5051 (92187953/100000002:100000002/100044550 games), extra komi 0.000000
> genmove in 3812.95s (26238 games/s, 13119 games/s/thread)
> tree pruned in 3.09944e-05 s, prev 0 s ago, dest depth 1 wanted 1, size 1717986952->88/429496729, playouts 92187953
> playing move C5
> Move:   5  Komi: 3.5  Handicap: 0  Captures B: 0 W: 0
>       A B C D E F        A B C D E F
>     +-------------+    +-------------+
>   6 | . . . . . . |  6 | x x X X x x |
>   5 | . . X). . . |  5 | x x X X x x |
>   4 | . . X X . . |  4 | , , X X , , |
>   3 | . . O O . . |  3 | , , o o , , |
>   2 | . . . . . . |  2 | , , , , , , |
>   1 | . . . . . . |  1 | , , , , , , |
>     +-------------+    +-------------+
> 
> = C5

  Overally, Pachi thinks it is losing, so after B4-E4-E5-E3 it resorts
to a silly move of B2. But the bug here is that move C5 (which is not
even expanded) has got a huge number of simulations, much more than the
principal simulation. This is due to the fact that (i) did not stop
the search after "memory limit hit" was printed. The bug happens only
if you fix the number of simulations, I have committed a fix now.

  Thanks for the report,

-- 
				Petr "Pasky" Baudis
UNIX is user friendly, it's just picky about who its friends are.



More information about the Computer-go mailing list