[Computer-go] About Minirock

Aja Huang ajahuang at gmail.com
Wed Feb 15 11:12:44 PST 2012


Hi Xaryl,

Surprised that Pachi's ladder code can't detect common second line kill like 
this:
.X.
XOX
...
###

But note in certain tactical situations it’s good to ladder-extend from the 
second line:
http://senseis.xmp.net/?TwoStoneEdgeSqueeze

Aja


From: Xaryl C
Sent: Wednesday, February 15, 2012 4:25 AM
To: computer-go at dvandva.org
Subject: Re: [Computer-go] About Minirock

Yes, it's correct that I use Pachi as foundation and have different playouts 
and search tree distribution.

I don't feel like to submit patches at the moment as the codes are 
horrendous,
but if you want, I can give you compilable codes (but no guarantee it is 
humanly readable... or can be compiled within 30 seconds :-p)

I don't even know if the bot is stronger than Pachi, but I will list some 
things I noticed about Pachi.
Some tests were done some time ago with 9x9 games that I don't remember the 
detail to well,  recent 19x19 tests are done with few playouts per move 
(4096 per move), and often I move on as long as the change passes binomial 
test, so I don't have good estimation on elo gain either.

In playout policy, 3x3 patterns can use some tactical checks or at least 
liberty checks; mogo patterns tends to end in crosscuts follow by nonsense 
too much. There's quite a bit of elo here.

The tactical reading codes can improve a bit too, for example, Pachi's 
ladder code can't detect common second line kill like this:
.X.
XOX
...
###
Heavier tactical readings sometimes don't provide too much elo by itself, 
but as long as it can probably "break even" in terms of speed vs elo, I kept 
them.
They might not produce much elo right the way because of the slow down, but 
it would allow one to add in heavier codes without slowing down the program 
as much (percentage wise) later on.

In playout permits, some moves can be rejected so the program can determine 
semeai/tsumego/seki better. These moves should be rejected in search tree as 
well. This might or might not "break even" in terms of speed vs elo depends 
on how slow the program currently is, but the effect is very noticeable 
against human players. Some people kept killing a small group in the 
beginning in a way that the program thinks it has good chance of living, and 
then the program would just slack off and lose regardless how many handi it 
has.
Just one warning, be really careful when rejecting moves, or the program 
will get into situations that it's losing but think it has good chance of 
winning and never passes or resigns.

The dynamic komi scheme works better for me by keeping the winrate between 
43% to 48% when losing, and between 50% to 60% when winning.
(Values not too carefully tuned, and only on 4096 per move self play even 
games).
60% feels a bit high but every time I try to decrease it, it seems to lose 
strength in even game self plays.
The max losing komi can also ramp down as the game reaches later stage.
Proper dynamic komi provides substantial elo gain at least at self play with 
small amount of playouts per move.

As to the priors, the original program uses somewhat different search tree 
heuristics, but it doesn't seem to matter much; seems like it's just about 
biasing the search distribution towards the right direction. However, I 
don't really like the idea of adding fake winning/losing counts.
5x5 patterns helps a quite a bit even with just hack-ish values. Besides 
professional games, mid dan games also helps. I am thinking incorporating 
high kyu games might help as well.
I've had my eyes on professor Rémi's 2007 Amsterdam paper since long ago, 
but never had the time or motivation to try it. Works or not, it's a cool 
way to determine the values at least :-p



> Date: Wed, 15 Feb 2012 03:37:07 +0100
> From: pasky at ucw.cz
> To: computer-go at dvandva.org
> Subject: Re: [Computer-go] About Minirock
>
> Hi!
>
> On Tue, Feb 14, 2012 at 04:11:01PM +0000, Xaryl C wrote:
> > I am the one responsible for the bot. I started coding a go bot when 
> > school was boring, that was when classical bots prevailed.
> > Then life got busy, I tried MC, made some nice progress in terms of 
> > strength, but never even got the chance to properly debug the multi 
> > threading codes.
> >
> > Then sometime ago, Minirock (the player) wanted to have a bot, so I 
> > hackishly glued (with macros and mass code replacing with scripts) and 
> > replaced the playout codes and search distribution along with tactical 
> > reading codes and pattern matchers onto Pachi's codes.
>
> Great, I'm happy Pachi is useful like this too! If I understand it
> right, you use Pachi as foundation with custom playout and tactics code?
> Or is it vice versa?
>
> If you have any patches / changes in mind for Pachi (not necessarily
> with any of your reading code, but even just whatever is needed for
> better integration of foreign code in Pachi), I will be glad to merge
> it. Or just if you have any feedback. :-)
>
> Best,
>
> -- 
> Petr "Pasky" Baudis
> Smart data structures and dumb code works a lot better
> than the other way around. -- Eric S. Raymond
> _______________________________________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go



--------------------------------------------------------------------------------
_______________________________________________
Computer-go mailing list
Computer-go at dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://computer-go.org/pipermail/computer-go/attachments/20120215/53564c96/attachment.html>


More information about the Computer-go mailing list