Re: Fuseki and Joseki Database with Neural Network

[David Mechner <mechner@xxxxxxxxxxxxxxxxx>]

Hi, Jeffrey.

> As you are a rather expert Go player, I'd be curious to see what 
> sort of problems are constrained by what types of knowledge.  
> Which ones require only "tactical fighting" or "influence", etc..

Of course, it's best to have all types of knowledge at your disposal
when solving any problem, as human players do - all subproblems in go
will have simple examples where rough limited knowledge would suffice
for a correct solution, and more difficult examples where more
knowledge, or more powerful methods are required. Take life and death,
for example (it's all about life & death anyway :). If there's a stone
sitting in the middle of a lot of empty space, it's easy to get a
routine that says it's safe. But when a block is surrounded, and there
are crosscuts and the surrounding enemy groups are themselves partially
surrounded, you just have to read (as far as anyone knows). 

So I think one key issue is how a go program can use a module that,
because it uses only some knowledge/techniques (e.g. only static
information, no reading), is only accurate in some cases.  One way is if
one of the outputs of the module is a "confidence." 

For example, if I had a fast (say, static) low-liberty tactics routine
that could correctly determine 25% of the time when and how a block with
5 or fewer liberties could be captured, but in the 75% where it wasn't
sure it /knew/ that it wasn't sure, I could use it to terminate our more
heavy-weight life & death reading in just that 25% of the cases. That
would save a lot of compute time. 

I guess in a way this is all just restating a pretty mundane idea - most
traditional go programs in effect do this - they'll have a heuristic
that recognizes surrounding empty space, one that detects eyes, etc.,
and combine the results (maybe taking the max) to get the overall
strength of the group. 

So the point (in this context - sorry to be so long-winded) is that the
knowledge you use in the representation to solve a subproblem really
depends on what accuracy you need, which in turn depends on how that
module will be used. 

For Go ML research, I think a fruitful approach would be to measure the
error not strictly by seeing whether each test problem is solved
correctly, but also whether the module claimed to have a correct
solution. 

This offers the possiblity of actually developing a successful (while
limited) module that could be truly useful in the context of a real go
playing program. You can also then do interesting experiments with
changing the representation, parameters, or architecture of the ML
system you're using and see how it affects performance.

-David