Re: [gnugo-devel] Interested in GNU GO development

[Gunnar Farnebäck]

Dan wrote:
> One thing that I think needs to get done is to implement persistent
> caching of semeai results so we can increase the semeai node
> limits. If you look in the function owl_attack() in owl.c you will
> see a call to search_persistent_owl_cache().  There is no
> corresponding call from the function owl_analyze_semeai().
> 
> Other people might have other projects to suggest.

Of the TODO list items, the ones I would recommend for someone who is
new to GNU Go and relatively speaking stronger at programming than
playing, are: 

 * Implement detection of superko violation in the board code. We
   probably only want this optionally in play_move() and in a variant
   of is_legal().

Superko is probably not helpful during reading but if we need to play
under superko rules, especially in a tournament, then we would at
least want to filter out superko violations in the final step of the
move generation. Easy to implement something, moderately difficult to
do it well.


 * Implement persistent caching in the semeai code. 

Same as Dan suggested. To the most part easy to implement (given the
existence of all other persistent caches). Good heuristics for the
computation of active area may take some work.


 * Integrate the time handling code in play_gtp.c with the autolevel
   code in clock.c. Alternatively, replace them both with something
   better. Basing it on some solid system identification theory and/or
   control theory wouldn't hurt.

I would only recommend this for someone with a solid electrical
engineering (or at the very least similar mathematics) background,
preferrably at a post-graduate level. For someone who knows the
relevant theory the implementation shouldn't be all that difficult.


 * Write a script which plays through the joseki databases and checks
   that the engine really generates a joseki move for all positions in
   the databases. This would also be interesting to run with the
   --nojosekidb option.

Requires knowledge about the sgf file format, GNU Go's joseki markup
and GNU Go's gtp interface. Given that, this is reasonably easy to
implement in some suitable scripting language.


 * Fuseki tuning by hand is difficult. People who are interested
   in doing machine learning experiments with GNU Go could try
   working with fuseki. This may be one of the areas with most
   potential for substantial and reasonably quick improvements.

This requires quite a bit of research into models/representations
giving a useful level of generalizability of positions. It would of
course help to have some practical experience and theoretical
understanding of machine learning methods but I believe there are some
people on the list who do have that and would be interested in helping
out once somebody got something started. All in all still a big and
difficult project though, but with a high potential for significant
strength improvement.

/Gunnar