gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [gnugo-devel] The Module Formerly Known As Endgame


From: Eric
Subject: RE: [gnugo-devel] The Module Formerly Known As Endgame
Date: Sat, 18 Sep 2004 13:21:57 -0700 (PDT)

--- David Fotland <address@hidden> wrote:

> Please give this a try and let us know how it works
> out.  Planning,
> (or goal directed search), is part of most of the
> strong programs
> already, and at least one of the early strong
> programs (Wilcox's
> program before Nemesis, in the late 70's) used it
> extensively.  Perhaps
> today's computers
> are fast enough that using this as a pure approach
> can make a strong
> program,
> even though history suggests otherwise.

Oh no, it's not the speed of computers that is at
issue here. What has changed over the years is our
approach to Planning.

Those traditional planning systems are all heavily
intertwined with domain specific knowledge about
playing Go. That's because search problems are
typically intractable, and people intuitively feel
that domain knowledge is required to prune the search.
However, the result had been that people felt Planning
was sluggish and unreliable.

But after 1995, the Graphplan planner changed all
that. The Graphplan experiment proved that an
exhaustive search could highly outperform any of those
domain-specific systems.

So now the emphasis is on small, tight Planning
"engines", and having an expressive Planning Domain
Definition Language. This has provided a way of both
specifying and executing formal domain models.

Not only did we get the desired speed-up, we also got
a mechanism for allowing the planning system user (the
Go game developer) to "program" the computer in a
manner, and at a level, which is intuitive to the
user; as opposed to having to specify all the details
of exactly what the computer should do, i.e. in a
procedural manner.

Eric





reply via email to

[Prev in Thread] Current Thread [Next in Thread]