[Pachi] Better semeai handling ?

lemonsqueeze lemonsqueeze at free.fr
Tue Apr 26 15:13:36 CEST 2016


Thanks, this makes more sense now.

I guess i should apologize for my previous comment on moggy:
I just ran some tests on kgs 6d games to get an idea of moggy's 
prediction rate and it does very well actually: 24%
(i made the engine return the most frequent move from a number of moggy 
runs)

It even beats the large pattern predictions which i thought would be 
better (around 21%)

Does it sound possible that alphago's fast policy could have same 
prediction power and yet be significantly stronger wrt semeais ?
Seems even more puzzling than before !


On 04/25/2016 05:49 PM, Petr Baudis wrote:
>    Hi,
>
> On Mon, Apr 25, 2016 at 02:42:06PM +0200, lemonsqueeze wrote:
>> I've been wondering how to improve semeais:
>>
>> I did some experiments reusing hashed moves from the tree in playouts as in
>> the alphago paper, it seems to work but only with early phases of the semeai
>> as the tree doesn't go very deep into it usually. So unless playout policy
>> can follow up on it doesn't seem to help much (or we'd need the tree to read
>> the whole sequence out somehow to have the moves in the hash table ? doesn't
>> look straight forward though ...)
>
>    yeah, not too straightforward.  I wrote a Masters Thesis on this. ;-)
> But without a large success.  In general, you might expect that the
> hashing should however help with the horizon effect anyway...
>
>> I'm playing with a moggy unit test to see what's going on in the playouts
>> (t-unit/moggy_semeai.t in my moggy_test branch on github). Looks like it
>> gets in trouble as soon as it's more than 2 liberties race:
>>
>> X . O X . O
>> X . O X . O
>> X . O X . O
>> . X X O O .
>> . . . . . .
>> . . . . . .
>>
>> So moggy could definitely use some help. The thing i don't understand is how
>> it can work for alphago. If i understand correctly their fast policy uses
>> probability distribution from pattern features as in Remi Coulom's 2007
>> paper, which is also what pachi's pattern.c implements and uses for priors,
>> but not for playouts. (I see there was once a playout/elo.c which did that.
>> Just wondering, what was the problem with it ?)
>
>    I never got it to work better than Moggy, pure and simple.  Not even
> if I gave it equal #playouts (it's quite slower).
>
>> It seems most of the features they use are also in moggy, but there must be
>> a big difference also (i doubt moggy gets 24% prediction rate =)
>> I guess this must be this one which we don't seem to have :
>>
>>    "Response pattern"   Move matches 12-point diamond pattern near
>>                         previous move
>>
>> So something like this ?
>>        *
>>      * * *
>>    * * . * *
>>      * * *
>>        *
>>
>> Maybe their definition of 12-point / 3x3 pattern is different too ?
>
>    I don't think it's anything but what you have shown. It should
> correspond to our d=4 gridcular patterns.
>
>>    "Patterns are based on stone colour (black/white/empy) and liberties
>>     (1, 2, ≥ 3) at each intersection of the pattern."
>>
>> I don't understand much about the pattern code, but it doesn't look like we
>> take liberties into account for 3x3 patterns, right ?
>
>    Nope, just atari status.  Long time ago, I did a quick experiment with
> machine learned rather than handcoded patterns and I don't remember the
> result clearly anymore, but it couldn't have been a big success.
>
>


More information about the Pachi mailing list