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

Re: computer-go:life and death



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.

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

> I understand :)  But I think Thomas Wolf has proven with his program that 
> explicit
> representation of the logic is not necessary to solve hard life and death 
> problems.

I think Thomas Wolf's work on life and death is excellent.  But that
approach really only works for quite circumscribed problems without a lot
of empty space inside.

> And again, I don't see the real difference in representing the problem 
> logic in 700
> "pattern rules", or in 3000 lines of C code.  The logic is the same in 
> either case,
> and is just as explicit.  Although the C code may not be as clear to 
> someone other
> than the original author :)

I wasn't really making a distinction between procedural and declarative
knowledge;  whatever works is good.  I think that coding the logic
procedurally is a good idea if you understand it very well and can
convince yourself that it is right.

Tim