> 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. Darren [1]: I touch on this in my paper, and slightly more so in the CG2010 slides: http://dcook.org/compgo/paper_team_experiment_9by9.html [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) _______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
