[gnugo-devel] GNU Go 3.3/3.5

[Arend Bayer]

> > GNU Go 3.2 has been released at ftp.gnu.org and in the CVS
> > at Savannah.gnu.org. The CVS release tag is rel-3-2.
>
> This of course also means that it's time for a new development series.
> Patches for 3.3.2 are welcome (3.3.1 has already been used).

And probably this is a good time for some discussion what we are heading
for in the near/not so near future.

Here is list of issues where I personally see clear potential for
improvement (meaning that there is a weakness and I at least have some
ideas for how to improve it). Missing is the owl code as I still don't
understand it well enough to have an opinion here, and as it has been
discussed a bit already.

Any opinions/comments? Naturally, I feel mostly responsible for no. 0,
and might also do some experiments for no. 2, as Gunnar has mentioned
already.

0. Try further curing of the --experimental-influence weaknesses.

1. Improve semai module so that it can be turned on by default.

2. Rewrite strategical evaluation to a strict before move/after move
   comparison. This has to use: moyo size, eye shape, esacpe values, ...

3. Try teaching GNU Go Honte/simplifying position, maybe using the active area
   of (owl_)attack of alive resp. (owl_)defense of dead strings/dragons as a
   way to measure the aji in the position.

4. Connection: Improve Tristan's/speedup Gunnar's reader.

5. Use standard tree branching methods everywhere for substantial speedup.

6. Replace dragon amalgamation by s.th. based on readconnect (and with it
   of course the connect/cutting move generator).

7. I'd like to write a new module to analyze fights involving multiple
   dragons.

Some comments:

No. 3: One example might be to reduce the permeability for black influence
around dead white stones in the active area -- similar things are possible
in many ways; I guess that they could be quite useful, only the tuning
is promising to be extremely delicate.

No. 4: I guess that iterative deepening could work very well together with
Gunnar's distance function.

No. 5: I still consider "Enhanced transposition cutoff" to be the next
thing to do here. (Would only require to change the ADD_CANDIDATE_MOVE
macro.)

No. 6: To me it is not even obvious how the information from the connection
analysis should be represented. The current amalgamation of worms into
dragons cannot encode non-transitivity; and handling this is one of the
biggest potentials for improvement in my opinions.

No. 7: In situations as e.g. after cross-cuts, with lots
of small not yet connected groups closely toghether, GNU Go has to call
the owl code for each of these single groups. This is extremely time costly
(and in my opinion one of the reasons why kyu players can beat GNU Go on
NNGS with high handicaps so easily by making lots of overplays: the playing
level often drops to 5 immediately in such situations); also, the results
of these computations are not exremely useful information.

A module that would "just" do:
 - a 5-8 moves deep alpha-beta search, maybe with a maximal allowed branching
   factor of 5
 - play defending/connecting/attacking moves, plus maybe a nobi
   sometimes and (rarely) a cut, or an iken tobi
 - makes some conservative guesses concerning dragon safeties
could be extremely useful here.

Of course this goes in the direction of lookahead. and would be highly
experimental; but even if it never turns out to be useful, it might teach
us a lot about the possibilities/limitations/design traps for a global
alpha-beta-reader. OTOH, I don't think it would need to be very good to beat
(under these specific circumstances) the current "call owl for each dragon"
analysis.

Looking at the list again, it seems to me that all of 0.-6. might be a
prerequisite for this new module  -- so maybe this is rather s.th. for
3.7 / 4.1...

Arend