Re: [gnugo-devel] GNU Go 3.3/3.5

[Gunnar Farneback]

Arend wrote:
> 0. Try further curing of the --experimental-influence weaknesses.
> [...]
> 2. Rewrite strategical evaluation to a strict before move/after move
>    comparison. This has to use: moyo size, eye shape, esacpe values, ...

There is much to gain here. A recent, and very illustrative, example
is the NNGS game gnugo-3.1.34-viking4-200204240801.sgf (available in
CVS). This is an even game against viking4, a program GNU Go usually
can beat at 6 stones. The start of the game is truly horrible. After
the first 51 moves viking4 is way ahead with a clearly superior
position. In the end GNU Go manages to win by a 100+ point margin, but
against a top program this start would have lead to a huge loss.

> 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.

The number of tactical nodes stored in the persistent cache may also
be useful as an indication of aji. One potential source of simplifying
moves are ones which connect (in the tactical readconnect sense) two
strings surrounding a dead opponent dragon with much aji.

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

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

These are high priority items on my agenda.

> 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.

There is no question that major changes are required here. I have some
ideas, but they are not very mature yet. I can try to give a rough
description of my current thoughts:

* All current amalgamation sources are thrown out.
* The dragons are built one at a time.
* The amalgamation process for a new dragon always starts with the
  largest free worm.
* The worms of the dragon are split into "core" and "tails" (these
  names may require revision).
* The first worm goes into the core.
* The neighborhood of the dragon is scanned for potential free worms
  to amalgamate with. When one is found which can't be disconnected
  (as determined by readconnect), it is added to the dragon as a tail.
* The neighborhood of the new tail is scanned for nearby free worms.
  The ones which can't be disconnected from the tail are marked. Then
  these are also tested whether they can be disconnected from the
  (closest) core. If all of them are securely connected, the tail is
  upgraded to core and the marked worms are added as tails.
* Repeat until the dragon has grown as much as it can.
* Repeat until there are no free worms left.
* It's probably also necessary to add amalgamation for links which can
  be cut in a readconnect sense, but where the moyo situation
  indicates that the cut is futile.
* No amalgamation around eyespaces.

Here's a bigger list, in no particular order, of things I'm
considering working on:

1. Implement a persistent cache for connections.

2. Improve the readconnect code, both in terms of speed and accuracy.

3. Extend the connection test suite. It should at least include
   examples of all the connection shapes/tesujis appearing in
   elementary books like Graded Go Problems, Tesuji, and Get Strong at
   Tesuji.

4. Revise the amalgamation scheme.

5. Revise the detection of cutting and connecting moves.

6. Rewrite the aftermath code in a pattern driven fashion.

7. Simplify the tactical reading code. There is much code which is
   effectively duplicated and there are way too many trymove() loops.
   My vision is to have just one trymove() loop for attack and one
   for defense, with different sets of move generators called
   depending on the number of liberties. This would of course do away
   with the various defend2(), defend3(), etc. functions.

8. The usual array of maintenance work. In particular I'm always
   looking for pieces of code which can be removed.

9. Various tuning and small fixes needed to solve specific test cases.

10. GTP revisions and specification.

11. Further improve the atari_atari code.

Dan wrote:
> These are all good ideas. (2), (6) and (7) seem projects for later.
> Actually for (2) I think it is important to eventually do this
> but there seem to be more urgent things first, (6) may be on 

I think you underestimate the value of (2).

/Gunnar