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

Re: computer-go:life and death

At 10:39 AM 5/29/2001 -0400, you wrote:


On Mon, 28 May 2001, David Fotland wrote:

> Many Faces understands goals during reading such as gain eyes, attack
> neighbors,
> run away, etc, and applies the goals that are appropriate during move
> generation.

I'm sure that everybody does goal-directed reading of some sort.  I just
haven't seen any program descriptions where the logical relationships
between all the relevant goals in a problem are represented (or computed)
in a convincingly correct way, not just heuristically in a way that works
well in practice.
To me the best evidence of correct understanding is getting the right answer
to problems :) I take more of an engineering approach of using what works without
worrying too much about theoretic elegance :) If the program doesn't understand
the relevant goals, it won't be able to solve the problems. You are right that these
programs have not been described, either because the authors don't have time, or
the algorithms are too complex to describe in a short paper.

I wasn't objecting to your approach, just to your incorrect description of the state of
the art in computer go. I don't think you have presented enough evidence in your thesis
to demonstrate that your approach will lead to stronger play. Certainly the results you
show are quite a bit weaker and slower than current programs. But of course the
current programs contain much more knowledge than is represented in your rules.


>
> Capturing a block to save another is pretty basic, and all programs can
> generate
> moves based on this knowledge.  But usually it is hard coded in a move
> generator, and
> not part of a set of rules that are expressed in a "rule" or "pattern"
> language.
>

Do your move generators have at their disposal knowledge of the logical
relationships between goals?  For example that capturing a block P is
possible iff P can be severed from block Q or severed from block R?  And
similiarly for block R and block Q and so on?  I'm sure most programs have
something like this for some goals but my impression is that is done in a
fairly ad hoc way.
Of course they have this knowledge. Otherwise they could not solve the problems
that need this knowledge. You are correct that the representation is quite ad-hoc,
and can't be formalized in the way you do it in your thesis.

I have a bias against trying to reason with exact knowledge in go, since I've tried it and it
didn't work. The results from this kind of reasoning always seem very brittle.

There are always exceptions to general rules. I prefer a probabilistic approach,
which leads to code with many heuristics, ad-hoc rules, and tuned constants :)
But it seems to work better this way.

David



Tim

David Fotland