[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [gnugo-devel] Owl and connections
From: |
Portela Fernand |
Subject: |
RE: [gnugo-devel] Owl and connections |
Date: |
Mon, 28 Oct 2002 22:24:13 +0100 |
Arend wrote:
> No, I didn't imply this.
Ok. Btw, I was only curious to know why my idea is wrong in case it is so.
> 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.).
After (re)reading the source, I agree that a simple update is a better
idea.
> 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.
Well, let me develop a bit. I think we only need 2 patterns in
owl_attackpats.db :
XO and X*X
*X
with a !oplay_connect(*,a,b) clause.
This should catch most (if not all) of the cases. Else, we will probably
have to
revise some patterns in owl_defendpats.db, like those which wrongly assume a
connection with a jump. For instance, in D13xx I've seen patterns like this
:
....
O.*.
....
without b classification. This should be reconsidered I think.
I guess it would be easy and light to implement things this way. Sure, we
won't
catch all the cases immediately, but we'll start finding a good deal of them
in
an (hopefully) inexpensive way.
In conclusion, I'd like to work around any performance issue possibly caused
by
a systematic approach with a pragmatic one. But if you're confident that you
can
solve the performance problem, then we'd better close the topic asap. :)
/nando