[gnugo-devel] Declarative Programming

[Eric]

--- Xavier Combelle <address@hidden> wrote:

> David G Doshay wrote:
> 
> > But then again, I have no idea what an AI Planner
> is or how
> > it works. I think in terms of algorithms and data
> structures.
> 
> I really don't know neither, but if I understood
> well a planner is something
> wich help to organize tasks, the more urgent first.

I'll send you something on this later today. It turns
out to be a very important point.

> My problem just now is that neither Eric Parker nor
> you did present what 
> they want
> to do with their programs. Do you want to sell it,
> give it to the FSF, 
> or just use
> it as a research purpose and keep it for you ? As
> you both communicate 
> on the gnugo mailing list,
> it's a very strange situation.

Ha ha, sorry about that. The problem is that I like to
think in more concrete terms. You know, bits and bytes
;-)

The logistics of technology transfer is a topic that
is  better debated amongst the more senior members of
this list. I'm open to any suggestions - I'm not shy -
I will quickly answer 'yes' or 'no' to each idea you
can come up with.

For example, I feel that posting the source code of my
planner on the Internet is a bad idea. It would create
a disproportionate playing field advantage: only a
dozen or so people in the world understand *why* AI
Planning is important to the future of computing. This
is how the Bill Gates of the world are born. We have
enough of those already ;-)

But I dont mind making the compiled program forever
"free" (small f), as opposed to making the source code
"Free" (capital F), if you get my drift, and if
there's a mechanism for doing this. Then GNU Go has a
"free" planner to link to (I think this was suggested
earlier on this list).

Personally, I just feel that it's way too early in the
game to discuss logistics right now. We are both
ignorant of each other's crafts. A small amount of
understanding should develop first.

In my opinion, the proper amount of understanding will
require that we develop some quick and dirty
prototype, i.e. with minimal, measurable
functionality, in order to prove the concept. At that
point we will be able to have a useful, knowledgeable
discussion about where to go next.

> But what I was speaking about was the underlying
> theory that Eric used.
> It appears that by making a highlevel strategy (for
> exemple what sluggo 
> does)
> and low level tactic (what gnugo is apparently)
> communicating
> together in both directions you have a better
> results than if the strategic
> module just use the results of the tactic.

Xavier, what I want to have is AI. Stragetic-tactic
glue is procedural programming. To accomplish AI, you
want to raise the (conceptual) level at which
instructions are specified to the computer.

AI Planning, in particular, is a form of declarative
programming. You provide human knowledge to the
computer using formal logic (don't right away be put
off by this, it is easier than you think!). In this
way it is not necessary to give the details of every
possible situation of the Go game (it is impossible to
do that). Instead, the program itself is capable of
(logically) "thinking". Really!

With procedural programming, there is a tight coupling
of human knowledge and program source code. With AI
Planning, human knowledge is *passed* to the program
in the form of a domain model. The (classical notion
of a) computer programmer is out of the loop at this
point. It is the domain modeller/expert who provides
the human knowledge to the program. The program simply
"executes" the domain model, and is capable of
(logically) *deriving* knowledge that wasn't provided
to it.

For example, without ever playing Go in my life, I
could easily model the Go domain simply by typing up a
set of "domain operators" that didn't know anything
else about Go other than the basic rules of the game.

Then, when the Planning engine executes my domain
model, it will perform a brute-force search, and
return to me the *perfect* move to make in any
situation; theoretically. The problem is that, in
practice, the program would run too slow to be of much
use. Domain experts are needed to adorn the domain
operators with human knowledge (in addition to game
knowledge) about the game of Go. Then the program will
run faster.

One of the advantages of this type of approach is that
you don't have to develop strategic-syntactic glue for
every application. Instead, you reuse the
top-down--bottom-up glue which is already internal to
the implementation of the reasoning engine.

In this way, there is a separation of responsibilities
between the computer programmers and the domain
experts. That is why I say it is not so important that
GNU Go be able to distribute my planner source code.
Any planner will do. It is rather the domain model
itself that will be interesting to the users.

Finally, with this paradigm, it is important to notice
that the distinction between "user" and "programmer"
has been blurred somewhat. We say that we have risen
the level at which the user provides instructions to
the computer. In other words, we have AI!

QED,

Eric