I'd like to introduce myself. I was a Shodan, when I was at my top strength (have maybe played a dozen games in the last 12 years), and I work professionally as a database programmer (mostly Access VBA, some SQL Server).
I'd been mulling about how a Go program might work on and off for many years. Last week, as a practice C++.NET project (I'm teaching myself a new computer language), I wrote a simple console interface for playing the game. Then, I took the further step of creating an "influence map" generator. This latter implementation seems to me to be rather promising. The resulting "topographical map" data can be created quickly and easily, yet seems to yield truly useful information, and could conceivably be part of the evaluation system for min-max searches.
Out of curiousity, I did a web search to see the state of Go programming these days, and came across the Gnu Go site. From your documentation website, you list as a need the following: "Create a way to quickly assess the safety of a group. This might take into account number of eyes / half eyes, moyo in corners, moyo along the edge, moyo in the center, proximity to living friendly groups, weak opponent groups etc. The point is that it should involve no reading and that it is quick. This could be used to make a strategic estimation of how a move strengthens a friendly group and/or weakens an opponent group and how strong/weak groups influence each other."
It seems to me that what I programmed would fit the bill. The idea is simple enough. I'd be surprised if no one implemented it before. I would be interested to know if it is something your team has used or considered using.
Theoretically, an influence topo map could have many uses:
(1) Compare overall changes in the "influence topography" of a move by summing ALL the topo values for every unoccuppied point.
(2) Get an approximate game score by counting the number of squares that are either elevated or depressed.
(3) Break the scoring into bands with differing significance. Perhaps there is a certain range that is ripe for invasion or erasure, another that would indicate over-concentration (e.g. gaining 10 points, from -5 to +5 is more significant than gaining 10 points from +40 to +50, the latter probably indicating an "overconcentrated" move).
(4) The presence or absence of high peaks/deep valleys could be used as a tool for estimating connection between stones, or the "life-force" of a group.
(5) Structures like eyes or moyos have defineable "influence" generating characteristics that might prove useful.
I do not worry about whether a stone is alive or dead. All stones have some "aji," alive or dead. If a stone is "dead" yet remains on the board, most usually the presence of opponent stones will overwhelm the dead stone's influence anyway, so a "life-force" factor in the equation seems unnecessary. But one could envision a situation where the "life-force" of a group alters the ability of that stone to exert influence. (And the influence in turn affects a group's "life-force" factor. Fortunately, the feedback loop seems to be negative.)
My current influence generator uses a tapering influence range of 8 moves. The rate of taper (per move) and the range can be easily adjusted. I have come up with what I think is an elegant addition to give stones near the edge of a board an appropriate amount of extra influence, so that the map yields values that seem to be realistic and consistent over the entire board, even corners. The algorithm trees out from a given square in a fairly efficient fashion, able to wrap around existing stones (it seems most logical to consider a stone as being opaque, and not allow any other stone's influence to pass through it) in every direction, yet also able to avoid reduncancies and duplications.
I believe one could fine tune the map and scoring evaluators by examining top level games where one can presume a certain balance is maintained. I have been very encouraged by the positions I have examined so far, but my "console application" is quite clumsy and limits my ability to do more research. Thus, I thought it wold be more fruitful to collaborate.
Would anyone on the Gnu-Go team like to look at this further? Perhaps this influence mapper could be made into a C++ class that could be easily linked and incorporated to your existing program.
By the way, could you tell me what the strength is of the current Gnu-Go program? And what the strength is of the current strongest Go program? I am also intrigued by what your team has done so far with encoding "josekis" of small technical matters such as shoulder hits, certain standard attachments and such. It seems to me these could be very useful in winnowing min-max trees. And if they could be fruitfully linked to the "influence topo map evaluations," this might add to the ability to weigh results of possible standard invasions and reducing moves, and thus give a Go program much better "long-term, long-range" strategy.