RE: [computer-go] Pattern Matcher (was M.Boon-Library)

["Mark Boon" <tesuji@xxxxxxxxx>]

> -----Original Message-----
> From: computer-go-bounces@xxxxxxxxxxxxxxxxx
> [mailto:computer-go-bounces@xxxxxxxxxxxxxxxxx]On Behalf Of Daniel Bump
> Sent: Wednesday, October 27, 2004 0:17
> To: computer-go@xxxxxxxxxxxxxxxxx
> Cc: bump@xxxxxxxxxxxxxxxxx
> Subject: Re: [computer-go] Pattern Matcher (was M.Boon-Library)
>
>
>
> Mark Boon wrote:
>
> > First of all I find your patterns very hard to read. Maybe this
> gets better
> > with a good editor?
>
> It gets better with practice. I think the editor is irrelevant
> since the patterns are written in ascii.
>

With this I disagree, the editor is very relevant. It may be ascii, but that
doesn't make it easy to read. When it's not easy to read then mistakes will
be made. I know this from experience.

> > I've heard about others using the '(opponents) stone or empty'
> but I find it
> > rarely useful. Although technically it happens that two patterns are the
> > same except for a position where there could be a stone or
> empty, as a Go
> > player I find that they are so inherently different that I would make an
> > extra pattern. Would it add more than a few percent in the number of
> > patterns in your case?
>
> It's hugely useful. Browse the GNU Go patterns and see how
> often o and x occur.

'Hugely useful' means you don't have to duplicate some patterns in your
library. The decision-tree doesn't get any different. Roughly for every x
and o you save a pattern. So how many o's and x's are we talking about in
total, on how many patterns? At least in the example given I question very
much if all those cases should be defined in one pattern. Either you missed
a much more fundamental principle in your pattern, or not all those cases
should actually be in the same pattern. In the example it seems to me the
condition ";!attack(A) && attack(a) && !oplay_defend(*,B)" already makes all
the x's obsolete.

>
> > What I miss is the opponents move. Generally patterns are such
> that either
> > player could be to move.
>
> I'm not sure what you mean by the second sentence. You might be
> expressing the proverb `my enemy's vital point is my vital point,'
> or you might be just saying you can't tell who's to move in the
> patterns.

Not at all. If it were for the proverb you quote, I wouldn't need a
different move for my opponent. In my case the proverb is: if the pattern is
important for my opponent, then it's important for me. I just may play a
different move in the pattern than my opponent. A pattern that defends my
group will have a move for my opponent to attack, etc...

>
> O is always the player to move, X is the opponent, and * is the
> location of the move. A few patterns are duplicated with the O's
> and X's reverse, especially in the owl patterns.
>
> > Generating C-code is not going to work for me, although it
> probably could
> > just as easily be generating Java code. But the real question
> is: how does
> > it perform? My pattern-matcher takes all the patterns in a set
> and (tries
> > to) constructs an optimal decision-tree to match the patterns
> in the least
> > number of steps. I wonder if by generating C-code you can reach the same
> > kind of optimization. I suppose in principle it should be
> possible, but it
> > seems so much more difficult to me. Or maybe it comes down to
> roughly the
> > same thing?
>
> The purpose of the DFA sounds similar to the decision tree you
> describe. The purpose of the C code in GNU Go's constraints is
> very general. For example you can call the reading code and
> ask if after several stones are played whether something can
> be captured.
>

I'm not talking about the constraints. The whole pattern-library is made
into a decision tree, or do we misunderstand each other here?

> GNU Go documentation on the web has just been revised:
>
> http://www.gnu.org/software/gnugo/gnugo_toc.html
>
> The pattern matcher is described in quite a bit of
> detail here:
>
> http://www.gnu.org/software/gnugo/gnugo_9.html#SEC108
>
> Dan
> _______________________________________________
> computer-go mailing list
> computer-go@xxxxxxxxxxxxxxxxx
> http://www.computer-go.org/mailman/listinfo/computer-go/
>

_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/