Re: [gnugo-devel] Contributing to GNU Go

[Arend Bayer]

Hi,

> Anyway, the real reason I'm writing is that I am teaching CS and have 10-12
> students who will be working on a project for the Fall semester.  I would love
> to have them work on GNU Go if we can find a suitable project.  There are a
> number of ideas mentioned on the task list that sound exciting.  The two most
> promising could involve applying machine learning (my background) to fuseki
> tuning or improving the group-safety heuristics.  Several others, such as
> speeding up tactical reading, also sound interesting but for the purposes of 
> my
> class, the students need the exercise of designing and implementing new code
> modules.  Perhaps two other ideas worth considering would be enabling GNU Go 
> to
> think during the opponent's move and making the engine run on a cluster of 
> machines.

> Please contact me if any of these ideas sound reasonable for my class.  As I
> said, there are 10-12 upper-division undergraduate students.  Factoring in 
> their
> experience levels and other commitments, I think we should estimate that they
> could contribute 2.5-3 full-time person months.  I look forward to hearing 
> from you.

Well, there are definitely a couple of interesting projects possibly to
be done. Of course it is a little hard to judge without knowing the
level of skills of your students, but 2.5-3 full-time person months
definitely sounds like s.th. useful could be done.

Projects that try to improve the level of play are certainly most
interesting, but have the inherent danger that they might not work out
well, i.e. that the new code doesn't give an improvement over the old
one.

My guess is that doing some machine-learning with fuseki would have
higher chances of success in that respect than with group-safety.
Speeding up the tactical reading should probably be dropped off the
list, as this is already a very highly optimized part of GNU Go.

Another possible project that comes to my mind is: Replacing the
"persistent owl cache" ("owl" means life-and-death reading) with a
scheme as used by "WinHonte" (another Go program), as I have described
very briefly in:
http://mail.gnu.org/archive/html/gnugo-devel/2003-08/msg00012.html.
This project would have the advantage that everyone can measure
whether it's doing s.th. good, without being a go expert.
(It would involve writing a new module to handle the DAG, and modifying
the existing code in owl.c to use it, so I think it would satisfy your
requirements.)

You are of course welcome to ask more questions on gnugo-devel.

Arend