Re: computer-go:life and death

[rtm@xxxxxxx]

Interesting thread.  On the one hand, David says, among other
things, that writing hand-crafted C code embodying the requisite
knowledge is _faster_ (in execution time).  On the other hand, I
remember a previous discussion in this list to the effect that
more computer power isn't really useful for computer go right now
because we don't have the algorithms to make use of it.

But aren't these two points of view contradictory?  Intuitively,
techniques involving a formal encoding of knowledge, which can
then be reasoned about and applied consistently, should over time
yield stronger, more maintainable, and more extensible programs
than would coding knowledge ad hoc in C.  Isn't using a
higher-level formalism for this aspect of the computer go problem
in one way conceptually not that different from using a
higher-level computer language to program in?  And as these types
of approaches evolve isn't there a strong likelihood that the
processing power will be there to support them?  Even now, I
mean, what's the point of a C program running on a 1.2GHz P4
machine and the program is so optimized that it can make a move
in 300 milliseconds anyway?

(By the way, speaking of performance questions, I ran a really
simple benchmark on the 1d vs. 2d board representation question
that came up on this list a few weeks ago, and the result was
that the 1d approach was about 25% faster.  I am betting that
that is less than many posters thought.  This benchmark is
basically doing _only_ coordinate arithmetic.  If you randomly
assume that the typical go program spends 10% of its time doing
coordinate arithmetic, the savings from the 1d representation is
therefore 2.5% across total execution time.  This seems too small
to worry about.)

Also, in my opinion, it's setting the bar too high to insist that
people working on things like knowledge representation prove
before their research is done that it will be successful.  I also
do not think that formal approaches to representing knowledge
necessarily needs to be incompatible with the probabilistic,
stochastic, or heuristic approaches that David espouses.

-- 
Bob Myers

On Tue, 29 May 2001, David Fotland wrote:

> [snip]
>
> 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.
>
> [snip]
>
> 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