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

["Mark Boon" <tesuji@xxxxxxxxx>]

Here I don't agree. The patterns represent Go knowledge that has specific
use to a specific application. I don't see patterns as general knowledge,
with the exception (maybe) of joseki.

XML is a possibility. But not necessary for the reasons you give. SQL is
just as standard and widely available through tools, if not more so than
XML. So accessing it from different languages is not a problem.

If someone would make a good pattern-editor based on SQL, XML or any other
easily accesible way, and take care of storage and retrieval from a
database, now that would come in very handy. But a pattern-editor is useless
if it can't edit some crucial extra information that I need to store with
it. So you will need to specify a language for this beforehand. This should
be doable. Hibernate stores my data structures in the database almost with
no programming, so I store the internal representation. But if someone has a
kick-ass pattern editor available based on XML, then I might be tempted to
use it.

I agree that the pattern representation, editing and storage is completely
separate from the matching algorithm.

> -----Original Message-----
> From: computer-go-bounces@xxxxxxxxxxxxxxxxx
> [mailto:computer-go-bounces@xxxxxxxxxxxxxxxxx]On Behalf Of David Weiss
> Sent: Tuesday, October 26, 2004 19:52
> To: computer-go
> Subject: Re: [computer-go] Pattern Matcher (was M.Boon-Library)
>
>
> Mark,
>
>      This sounds like something which will be
> extremely useful.  Thanks for taking the time to
> do this.
>
>      In my opinion, the actual pattern data will be
> more valuable than the pattern matching or pattern
> editing code.  I would suggest using XML as the
> pattern language.  The reasons for this are as
> follows:
>
> 1) The pattern data can be used from a variety of
> languages, as there are standard tools for parsing and
> creating XML in a variety of languages.
>
> 2) There are standard tools for transforming XML into
> other languages, so individual programs can use their
> own format for representing the patterns which can be
> generated automatically from the XML.
>
> 3) It is difficult to devise a complete pattern
> matching language in advance, so the first version can
> incorporate the attributes which you are already using
> such as the number of liberties, and future versions
> of the language can add new attributes as necessary.
>
>      This is stating the problem a little differently
> than in your original post.  In my view, there should
> be a standard pattern language.  The pattern editor
> can be written once, but the pattern matcher would
> need to be written in the specific language being
> used by the application, at least C and Java.
>
>
>
> __________________________________
> 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/
>

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