Re: [gnugo-devel] Some questions about GNU Go's status and future

[Gunnar Farnebäck]

On 06/08/2013 10:25 AM, Chad Williamson wrote:
> Hello all,
>
> I notice in the git log that it's been a couple years since the last
> entry, with development sputtering out completely after the 3.9.1
> release in December 2010. It would appear that rise of Monte Carlo
> methods was a major factor in the tail-off leading up to that, with the
> MCTS implementation in montecarlo.c quickly falling behind the state of
> the art.

GNU Go's Monte Carlo implementation was somewhat okay for 9x9 but 
unfortunately never anywhere near state of the art on larger boards.

> It's pointed out in the TODO file that the classical engine in GNU Go
> was written before multithreading was an everyday concern, and that
> seems to affect the Monte Carlo effort as well (the many global
> variables in board.h aren't much more conducive to playouts than they
> are to thread safety, etc.).

Using the normal board code for Monte Carlo would indeed be a nightmare, 
which is why I implemented custom Monte Carlo board code in 
montecarlo.c. That was designed from the start to be thread friendly.

> Petri Pitkanen alluded recently in this list
> (http://lists.gnu.org/archive/html/gnugo-devel/2013-05/msg00002.html) to
> the possibility of informing MCTS with GG knowledge. Similar thoughts
> are mentioned in the TODO file: "Make the Monte Carlo search and/or
> simulations take advantage of the tactical/connection/owl/semeai reading
> results. [Extremely difficult]." Presumably the indicated engineering
> difficulty is the crux of the matter, but it seems to me that unless
> such a thing is done, this project is effectively dead (barring some
> newfangled class of algorithms scrambling the landscape again).

Yes, this is where there's potential to do fun and interesting things 
which can't easily be done in an arbitrary Monte Carlo engine.

> It seems substantial prep work to modernize the structure of the of the
> historical GG engine would be called for, along with some serious
> refactoring, after which one could *start* to tackle the above
> integration with some hope of success (assuming there's some strength
> pay-off to be had by going that route).

I would say the critical point is to improve the Monte Carlo code (with 
standard Monte Carlo techniques) to a useful level. Then it makes sense 
to attempt crossovers between classical and Monte Carlo algorithms.

> With all that said, I have two questions:
> (1) Is this a fair assessment of the situation?
> (2) Is the community open to such an effort? (is there a community to
> speak of, anymore?)

I'm open for continued development of the GNU Go code.

/Gunnar