Re: computer-go:life and death

[David Mechner <mechner@xxxxxxxxxxx>]

The contribution of Tim's thesis is to describe our approach in a coherent
logical framework; to demonstrate that it works, how it works, and why it
works. To say that people already do something like this only the reasoning
is implicit and ad-hoc and they couldn't be bothered to tell anyone else
about it is just bogus.

Also, I don't think that the description of the state of the art in computer
go was inaccurate. The point being made was that go programs suck at life
and death - it's one of the things holding them back. The example position
given may not have been the best, but the point is valid.

The question of whether our approach will ultimately lead to a stronger
program (or even a stronger life and death reader) will remain an open until
we (or someone else) devotes the time and effort to extend the pattern base
to "full scale" - not a trivial project.

But at least we've done something that others can use in the meanwhile.

> 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.


I don't think that using a probabilistic approach necessarily entails an ad
hoc approach (or maybe you were kidding?) - what Tim and I did could be
fairly naturally extended to use probabilities instead of Boolean values
(though it might wreak with the logical formalism :)

-David Mechner



----- Original Message -----
From: "David Fotland" <fotland@xxxxxxxxxxxxxxxxx>
To: <computer-go@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, May 29, 2001 11:56 AM
Subject: 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