[Computer-go] About Minirock

Xaryl C xaryl at hotmail.de
Wed Feb 15 03:25:00 PST 2012

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:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://computer-go.org/pipermail/computer-go/attachments/20120215/88ac68ac/attachment.html>

More information about the Computer-go mailing list