[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [computer-go] Pattern Matcher (was M.Boon-Library)
It would nice to have a standard format for patterns.
This could either be the GNU Go one, or one which
is readily easily converted to that one
programatically. I agree that the GNU Go one is not
that easy to read. The important thing is that the
same types of patterns can be expressed in each.
The details are just a matter of personal preference.
The important thing is that the GNU Go patterns would
easily be able to be used by the Java program,
and vice-versa.
--- Mark Boon <tesuji@xxxxxxxxxxxxxxxxx> wrote:
> I have some comments and some questions. The
> comments are mostly based on
> personal preference, so please don't take it
> personal.
>
> First of all I find your patterns very hard to read.
> Maybe this gets better
> with a good editor?
> 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?
>
> What I miss is the opponents move. Generally
> patterns are such that either
> player could be to move.
>
> Your extra conditions are not really any different
> than the ones I
> described. I used a letter where you use a
> function-name. Of course the
> function-name is more readable. On the other hand I
> think using a coordinate
> is easier on the eyes than cluttering the patterns
> with As and Bs. But these
> are minor things. What it comes down to is that
> extra conditions are needed
> and how to make a general tool that allows for
> these.
>
> 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?
>
> Mark
>
> > -----Original Message-----
> > From: computer-go-bounces@xxxxxxxxxxxxxxxxx
> > [mailto:computer-go-bounces@xxxxxxxxxxxxxxxxx]On
> Behalf Of Paul Pogonyshev
> > Sent: Wednesday, October 27, 2004 1:13
> > To: computer-go
> > Subject: Re: [computer-go] Pattern Matcher (was
> M.Boon-Library)
> >
> >
> > Mark Boon wrote:
> >
> > > ...But a pattern-editor is useless if it can't
> edit some crucial extra
> > > information that I need to store with it...
> >
> > GNU Go patterns are stored in plain text files,
> which are then converted
> > into C sources by a utility program. This means
> you can use any text
> > editor as a pattern editor, even if not
> particularly convenient one.
> >
> > Additional information is stored as C-style
> expressions (though not real
> > C). Here is a real example of a pattern:
> >
> >
> > Pattern A1106
> >
> > OO.?
> > XOX* capture cutting stone to defend
> > xYO.
> > xx..
> > ----
> >
> > :8,C,value(70)
> >
> > OO.?
> > XOB*
> > xAa.
> > xx..
> > ----
> >
> > ;!attack(A) && attack(a) && !oplay_defend(*,B)
> >
> >
> > First goes the pattern name (GNU Go shows it in
> traces, so we can jump
> > right to the pattern which e.g. suggests a bad
> move.) Then comes the
> > pattern diagram with a short comment.
> >
> > . --- empty
> > O --- player's stone
> > o --- player's stone or empty
> > X --- opponent's stone
> > x --- opponent's stone or empty
> > ? --- anything
> > * --- empty; a move here is suggested
> > - --- board edge
> >
> > The line started with colon gives a few attributes
> to the pattern: no
> > symmetry, the move can cut the attacked dragon
> apart, value 70 (high.)
> >
> > After that a second (constraint) diagram comes.
> The only purpose of
> > this diagram is to define labels with respect to
> the pattern. Otherwise
> > it must match the main diagram.
> >
> > Finally comes the C-style constraint. It can be
> read like this:
> >
> > Match pattern if the opponent string at 'A'
> cannot be tactically
> > attacked, our lone stone at 'a' can be and if
> the opponent cannot
> > defend the 'B' stone after we play at '*'.
> >
> > I think this constraint style is very powerful for
> hand-written patterns.
> > You can always add more pseudo-functions and you
> are virtually unlimited
> > in what you evaluate here.
> >
> > Paul
> > _______________________________________________
> > 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/
>
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/