Re: computer-go: A problem with understanding lookahead

[Heikki Levanto <heikki@xxxxxx>]

Dave Dyer <ddyer@xxxxxxxxxxxxxxxxx> wrote:
> In go, there are no such metrics.

Ok, idle speculation: What sort of metrics could be useful in go? Never
mindthe branching facor, just speculate on what we could possibly use for
determining if we like one position better than another?

Counting the number of stones on the board is clearly not sufficient, it has
no relation to the final score. 

Counting the number of living groups is possibly very expensive, we can
disregard that.

One good indicator - though no way perfect - is the number of disconnected
groups. If all your stones are connected, you can not be badly behind.
Possibly this could be extended by ignoring single stones, or grpups of only
2-3-4 stones, and by adding some measure of the territory immediately around
these connected groups?


What else?


Number of corners controlled (how ever) by one player - if any one player
has all four corners in a handicap game - white wins.

Number of simple good and bad shapes. Just count the number of empty
triangles and pnnukis.


What else?


Number of forcing moves (peeps etc)

Game history: Number of times a player has responded locally vs remotely?


What else?


As long as we consider only a few ply deep, we can assume that the initial
analysis of the situation is sort of relevant for the later moves as well.
So in the beginning we can estimate thelivelihood of groups etc. On deeper
plys we can count the number of groups affected by the searched moves,
number of decisions made by each player, and what not.


What else?


I am sure you all can come up with other metrics that can be measured 
from a position.

The next question is of course how to combine all of these into a single
evaluation. Here some sort of learning algorithm might come in handy.

To test all of this we just need a generc go program based on global
searching, and an easy way to play with the evaluator. Is this something
the OpenGo project could be providing?


Personally I do not beleve this sort of approach will ever produce a viable
go program, but then again, something like this seems to apply for chess, so
who knows? Only one way to find out. And the computers keep getting faster,
so maybe some day we can afford this sort of approach. Would be nice to have
some theoretical foundation ready for that day...


-H


-- 
Heikki Levanto     LSD Levanto Software Development   heikki@xxxxxxxxxxxxxxxxx
               "In Murphy we Turst"