[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [gnugo-devel] Owl and connections
From: |
Arend Bayer |
Subject: |
RE: [gnugo-devel] Owl and connections |
Date: |
Mon, 28 Oct 2002 15:49:09 -0500 (EST) |
Portela Fernand wrote:
> Arend wrote:
>
> > It sounds for too expensive to test all relevant connections at each move.
> > However maybe one could misuse compute_connection_distances() in the
> > following way:
> > At each move, we compute the distances for a few of the core worms of the
> > dragon (or maybe all of them, but that might already be too expensive). We
> > remember the distances. Whenever a distance between two worms jumps up,
> > we suspect there could now be a cut, and test for it.
>
> I infer from the preceding that you don't think that the idea I presented in
> http://mail.gnu.org/pipermail/gnugo-devel/2002-October/003245.html is any
> good.
> Can you please confirm ?
No, I didn't imply this. A lot of what you mentioned will necessarily be
part of any way to deal with cut goal dragons (i.e. identifying the cut,
choosing the new target, updating local_owl_data (I don't think it is
necessary to create a new one, but that is a minor point), etc.). The main
problem is identifying when and where a cut happens.
If I understand your idea correctly, you want to make it a property of the
attack pattern to say that this move cuts s.th. off. This is certainly
useful for patterns where this is clear, but I fear that we will not be
able to capture most cuts just from the patterns. Most owl patterns simply
don't have enough context to decide this, I think.
(I don't think of your suggestions and mine as exclusive.)
> (...) but it looks tough to make it inexpensive.
Agreed. (compute_connection_distances() itself is probably not very
expensive, it looks comparable to eye space or escape value computations.
Testing for a cut by calling disconnect() is probably the expensive part.
Might need to drastically limit reading depths or max reading nodes.)
Arend