Re: [gnugo-devel] On the Role of Domain Experts

[Eric]

--- Evan Daniel <address@hidden> wrote:

> On Sun, 12 Sep 2004 20:22:49 -0700 (PDT), Eric
> <address@hidden> wrote:
> 
> > I have an idea, Evan. I'll *implement* and you can
> > *test*. Deal?
> 
> Sure, though at only a marginal 1d, I'm hardly the
> best person to ask.
> 
> I'm still somewhat unclear exactly what you intend
> to implement to
> start with, but I guess I'll find out soon enough :)
> 
> Anyway, whatever it is, please make sure that it is
> accessible through
> GTP and therefore the GNU Go test framework.
> 
> Evan Daniel
> 
> 
> _______________________________________________
> gnugo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnugo-devel

Hey Evan,

It has become apparent that the proper way to play
this logistical game with GPL is probably to credit my
contribution as the construction of a Planning
knowledge base (KB), in addition to Gnu Go's
collection of pattern-matching knowledge bases.

In fact, it is the domain model, i.e. the set of
domain operators, or the knowledge base, that will be
the significant result of our interaction.

The prototype I want to build will not in general be
useful beyond its purpose as a tool to assist in the
development of the domain model. In other words, the
prototype will be a throw-away. I just want something
quick, cheap and dirty, in order to prove the concept.

The purpose of the domain model will be to provide a
leg-up to those future GNU Go developers that may want
to try to use planners to play Go. In the least, these
future developers will be able to test their
implementations with an existing GNU Go Planning KB,
prior to experimenting with their own modelling
techniques.

This approach seems reasonable, as Semsyn and GNU Go
(at least the parts I want to use) are already
finished, and there doesnt seem to be any immediately
compelling reason for distributing a GNU Go with
Planning ability, i.e. for developing any code.

In fact, I can use the Graphplan planner to develop my
prototype, and not even use my personal Semsyn planner
at all for the project. This also solves a big problem
that Semsyn is written in Lisp (C is not very good for
fast prototyping, although people try to do it). But
since GNU Go and Graphplan are both written in C, then
Graphplan is better-suited for the job than Semsyn.

So, at the highest level, I have 2 independent engines
- a Go-playing engine and a Planning engine - and I
want to write a driver program that intermingles the
calling of their functions, and that performs the back
and forth translation of their data.

In my next mail, I will try to outline the main
operations of the driver program.

Cheers,

Eric