[Computer-go] Optimistic Majority Parallelization

Darren Cook darren at dcook.org
Sun Nov 28 22:26:42 PST 2010

> I tried parallelization of two machines.
> 1. Run same program independently on 2 machines.
> 2. A plays E5 and its winrate is 0.51
> 3. B plays F3 and its winrate is 0.53
> 4. Program plays F3 (select higher winrate move).
> Thus, very simple.
> Use same hardware, and random seed must be different.

I believe this idea really comes to fruition when you use two or more
very different (but still strong) programs; and an algorithm that keeps
searching until all programs agree rather than trying to be democratic [1].

If you want to stick with open source programs, perhaps two versions of
fuego, one with a patch for better seki handling [2].

I also have one team member which is Gnugo on self-play to the end of
the game (i.e. a single very heavy playout). Still weaker than the MCTS
programs overall, but on a few positions it scores it correctly where
all the MCTS programs get it wrong.


[1]: I touch on this in my paper, and slightly more so in the CG2010 slides:

[2]: I couldn't find a public source for this, but Martin Mueller told
me if you remove the balancer part of "if (selfatari &&
balancer.Play(toPlay))"  (i.e. just leaving "if(selfatari)") in
GoUctUtil's GeneratePoint() and IsMutualAtari() then you get much
stronger seki handling but a weaker program overall).
Unfortunately I've still yet to try it.

Darren Cook, Software Researcher/Developer

http://dcook.org/gobet/  (Shodan Go Bet - who will win?)
http://dcook.org/work/ (About me and my work)
http://dcook.org/blogs.html (My blogs and articles)

More information about the Computer-go mailing list