Re: [gnugo-devel] Readconnect

[Gunnar Farneback]

Tristan wrote:
> I was thinking of:
> 
> D5 C5 C6 D6 B7 B8 C8 C7 B6 B9 A8 C9 A9 A7 A6 B5 A10 A5 A7 B11 C10 C11
> D10 D11 E9 D8 D12
> 
> Do you see a way for white to connect ?

That line looks convincing. I got lost somewhere along the road and
ended up in a ko.

> I am not sure this one is easily solvable by a computer in a few time,
> given that Golois finds the solution because he does not understand
> that enclosed string with four liberties can be captured...
> Do you have a way to see that in gnugo ?
> (I mean the D5 C5 C6 D6 B6 B8 sequence)

GNU Go also fails with the tactical reading in this variation. I don't
really expect GNU Go to be able to get this connection problem right.

Dan wrote:
> Maybe we should link the code in right now on an experimental
> basis, the same way the new semeai code is experimentally
> linked in now.

For the time being I think it's more constructive to work with the
connect/disconnect test cases in connect.tst and connection.tst.

Tristan wrote:
> Is it possible to test readconnect on these mistakes ?
> Where can I find them ?

There are more connection mistakes in connection.tst. Also you can
frequently find connection mistakes in NNGS games. The real problem is
with non-transitivities. The simple connections it usually gets right.

> One thing you can do is write and optimize the move ordering in 
> 
> moves_to_prevent_connection_in_two_moves
> moves_to_connect_in_three_moves
> 

I have a patch which adds some code to
moves_to_connect_in_three_moves(), but I'll take that in a separate
message.

> What we should do, is enable gnugo to solve these test cases
> by using connection reading, and add some more tests to avoid
> useless moves that connects when strings are already connected,
> but the connection reader fails to see it.

What kind of positions are you thinking of here?

Dan wrote:
> It seems to me that we should continue to use the pattern
> matcher to find candidates dragons then use string_connect()
> to decide whether the match is valid. If Gunnar agrees with
> this plan, probably it is easiest if we implement it. Gunnar
> might have a different idea of how it should work, though.
> 
> Gunnar, is this how you'd do it?

I wouldn't start in this end. I would do the linking with the rest of
the engine in this order:

1. Revise induce_secondary_move_reasons() to make use of readconnect.
This should make the code simpler and more robust.

2. Replace all B and C patterns in patterns.db and patterns2.db with a
new module, possibly pattern driven, which uses readconnect to find
connecting and cutting moves.

3. Throw out the amalgamation code and replace it by something based
on readconnect. This would involve replacing find_connections() and
find_cuts() but more important is to take down the automatic
amalgamation around eyespaces.

4. Replace jump_out_helper and similar with readconnect based
conditions. In general many patterns which require a safe move would
be better served with a "can connect" kind of constraint.

5. Revise the owl reading to make use of readconnect.

First, however, it would be a good idea to implement some kind of
caching of the connection results.

Tristan wrote:
> What is really needed now is the function 
> prevent_connection_in_three_moves, I can write
> it, but maybe you already have written what I need,
> that is a function to compute second order liberties
> , and a function to check if an intersection is
> a second order liberty of a string efficiently
> (in Golois I have a bitmap of the board that
> can tell the result in one bit lookup).

I'll have a look at this.

/Gunnar