Re: Fuseki and Joseki Database with Neural Network

[David Mechner <mechner@xxxxxxxxxxxxxxxxx>]

Juergen wrote:

> But i think, the time will not be the main problem. Rather to find a
> really good evaluation function which will work for genetic algorithm.
> I mean, it is impossible to find one.
> Why?

It sounds like you're saying you need the go evaluation function to use
GA. That would be a problem. But in this context, I thought the idea
would be to use the presence/absence of the suggested move in the
traditional joseki database as the objective function.

> For GA we need a function with a steady course (i don't know if it is
> the correct mathematical expression for a function without any 
> 'jumps').

I think "continuous" is the word you're looking for. But you certainly
don't need a continuous objective function for GA. You don't need a
continuous "target" function for neural nets for that matter. 

> And thats the problem. I think we can't find such a function 
> because in "go" it's possible a stone placed on a field maybe 
> bad but the field next to it could be very good. It is not a 
> little bit better or something like that, it could be like day 
> and night. That produce a 'jump' in the function.

The nonlinearity/discontinuity of the go evaluation function poses no
special problem for GA in and of itself.

One real problem for GA is that it's totally unclear how to encode the
solution as a binary string. Even if you do come up with a scheme that
reduces the problem to some finite number of variables that a GA can
operate on, you'll have fixed the basic structure of the solution and
you'll have no guarantee that you haven't omitted something crucial -
you won't know that there's a good solution in your search space to
start with. 

GP (genetic programming, where a program is evolved rather than a binary
string representing a set of numbers) is more flexible in this regard,
but here the staggering size of the search space (the space of
programs!) is a serious problem. You can limit the size of the program
being evolved, but then you start running into the possibility of
excluding all the good solutions from the search space again. There are
other, problems too. Still, fun to think about.

Imho, the direction that people should be going in, with regard to
machine learning approaches to computer go, is to:

1) think hard about improving the representation of the problem that the
system works off of - don't just feed it the raw board position and hope
it will figure out about eyes, life, connectivity, etc.

2) rather than just trying to solve go, attack subproblems: move
ordering during tactical search, evaluating whether a point will end up
as territory, whether groups will end up alive or dead, whether
releationships are severable, whether a stone is tactically capturable,
etc. 

-David

-- 
David A. Mechner            Center for Neural Science
mechner@xxxxxxxxxxxxxxxxx         4 Washington Place, New York, NY 10003
212.998.3580                http://cns.nyu.edu/~mechner/