[Computer-go] About Minirock
ajahuang at gmail.com
Wed Feb 15 11:12:44 PST 2012
Surprised that Pachi's ladder code can't detect common second line kill like
But note in certain tactical situations it’s good to ladder-extend from the
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
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:
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
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
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
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
> 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. :-)
> 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
Computer-go mailing list
Computer-go at dvandva.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Computer-go