gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] readconnect patch


From: Tristan Cazenave
Subject: Re: [gnugo-devel] readconnect patch
Date: Tue, 06 Nov 2001 23:16:03 +0100

Gunnar Farneback a écrit :
> 
> Tristan wrote:
> > > The test case is for white to try to disconnect a black two space jump
> > > on the third line. The correct answer is that it can't be
> > > disconnected, but GNU Go from current CVS says that it is disconnected
> > > as it stands.
> >
> > it should say it can be connected and can be disconnected.
> 
> Should the program or the test case say that? As far as I can see the
> two stones are connected as it stands. GNU Go currently says
> 
> K17 and G17 can be connected at J17 (35 variations)
> K17 and G17 are disconnected as it stands (21 variations)
> 
> which is obviously inconsistent.
> 
> By the way, if two strings can't be disconnected, do you require
> connect to return PASS as move, or is it allowed to suggest a move,
> like J17 above?
> 

connect send back 1 if the strings can be connected.
disconnect sends back 1 if the two strings can be disconnected.

in that case both send 1, but it is not inconsistent.

The way I use these functions is that I first call connect to
see if the strings can be connected, and only if they can
be connected, I call disconnect to see if they can be
disconnected. If they can't then the move found by connect
is useless.

> > yes, the code can detect that it can be connected, then
> > when connection is proved, it can try the disconnecting moves.
> > This case is a hard one as I previously said, it requires ip51111
> > for the first example, and a simple ip6something function for the
> > second case. However, the second case can be simplified considering
> > strings linked by protected intersections as connected.
> 
> Is a two space jump on the third line really a hard connection
> problem? I would have thought the program needs to be able to handle
> much tougher ones.
> 

You may find it simple because every go player knows it as they know
the pattern... From a pure reading point of view it is not so simple
to prove it cannot be disconnected. Some connections you would find
difficult may be more simple from a search point of view.
However for such cases that arise again and again and that are
difficult to handle by search, it is better to have a pattern,
search is better for not usal cases. I included it in the test
suite because I want Golois to find it by search to test the
search algorithm.


> > > |..O......
> > > |.OOX.....
> > > |.OXX.....
> > > |.XOX.....
> > > |.XOO.....
> > > |.XOXXX...
> > > |.OXX.....
> > > |.OOO.....
> > > |.........
> > >
> > > where white to connect is an ipN game for some big N.
> > >
> > > I guess I'm missing something, or is this just a too difficult
> > > position?
> > >
> >
> > Capture of common adjacent strings are treated
> > by calling the capture code in Golois.
> 
> Notice that in the problem above, just capturing the white stones if
> they try to move out doesn't suffice. It's necessary to capture them
> in a ladder.
> 
> But in general I agree that the tactical reading should be used
> wherever it's useful in the connection analysis. The appended patch
> let's the readconnect code make use of the full-featured tactical
> reading in GNU Go, not only the naive_ladder() function, from a few
> places. This solves test cases 3, 35, 47, 56, and 73. It doesn't solve
> test case 2 but it comes closer by at least understanding that it's
> not disconnected as it stands.
> 
> However, this almost certainly destroys any possibilities to keep
> track of relevancy zones. The tactical reading has a related "shadow"
> concept but this is not quite as strictly computed as the relevancy
> zones in the paper. Thus this patch is not intended for CVS.
> 

I am still quite unhappy with my own relevancy zone computations...

> > You can define gradual games as simple functions,
> > you do not need to redefine gradual functions
> > for each game.
> > here is how it is done in Golois (I am sure it can be
> > improved), please ask me the unclear meaning of the
> > french words you have problem with:
> 
> Uh, sorry, but I'm afraid that would be most of the words in my case.

english version coming soon.

> 
> How large part of connect.tst does Golois pass?

I will send results as soon as I have implemented the PlayGtp part...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]