Re: computer-go: Insight of a human continued

[Don Dailey <drd@xxxxxxxxxxxxxxxxxxxxx>]

   From: "Mark Boon" <tesuji@xxxxxxxxxxxxxxxxx>

   ----- Original Message -----
   From: David Fotland <fotland@xxxxxxxxxxxxxxxxx>
   To: <computer-go@xxxxxxxxxxxxxxxxx>; <computer-go@xxxxxxxxxxxxxxxxx>
   Sent: Saturday, September 02, 2000 1:12 AM
   Subject: Re: computer-go: Insight of a human continued


   > >
   > >By the way, as for the discussion about patterns: I don't think patterns
   > >are obsolete in a good go-playing program, at least not if you are
   > >trying to play like a human player. Human players use patterns to
   > >consider whole candidate sequences instead of single moves, e.g. this
   > >white crosscut happens a lot
   >
   > Many Faces also associates sequences of moves with patterns.
   >

   In the early days, Goliath also used sequences. The main reason was that my
   evaluation function was very expensive and by using sequences I could get
   away with skipping evaluation of the internal nodes. I found it too
   inflexible however, leading to some very stupid plays in situations where
   the sequence matched but was highly inappropriate. So as soon as my
   evaluation function got faster (and computers got faster) I removed the
   sequences and replaced them by single-move patterns, where the patterns for
   the internal nodes had a high urgency value. Since then I have been tempted
   to reinstate sequences several times, because the program occasionally
   showed lack of consistency in its play. As written here before, I'm now
   convinced that the lack of consistency is a more fundamental problem that
   can only be solved by improving the programs understanding of the situation
   at hand. Patterns and sequences should only be used as time-savers, but the
   program should also be able to get to the same result without them.

   But of course, in real life one wants to (temporarily) improve the programs
   play as quickly as possible with whatever opportunistic means there are
   currently at hand. And nothing seems more painful than having spent many
   days implementing something that computes some end-result that could also
   have been reached by a few rules of thumb. That is, until the exceptions to
   the rules start to get noticed...

       Mark



Hi Mark,

I know  exactly what you are  talking about.  Sometimes it's very easy
to fix a basic problem  with  a rule  that  is usually right, and  yet
doesn't really address the problem very directly.

Don