Re: [gnugo-devel] endgame module for GNU Go

[Eric]

Hi Xavier,

The paper "Cooperation Between Top-Down and Bottom-Up
Theorem Provers" was not written by me. I just list it
as a reference.

It seems to me that you understand well what is going
on there. However, I'm not sure how easy it would be
to use the same approach for GNU Go.

You really need to have more than just a desire for
two modules to cooperate with each other. You see,
theorem provers (and AI planners) are formal systems,
whereas GNU Go is not. So things are a lot less
predictable with GNU Go.

Further, although the authors of the paper do a great
job, it is very difficult to have cooperating theorem
provers. Theorem provers operate on logical sentences,
and there are an infinite number of these sentences.

AI planners make use of formal logic as well, but they
typically operate on states, instead of logical
sentences. States are finite in size - there are a
finite number of state variables, and a finite number
of values that each variable can take on.

Even with this simplification, it has still taken me 6
years to find the right "glue code" to get the pieces
of my planner to cooperate.

You may be able to "glue" GNU Go's strategic and
tactical modules. I'm not sure. I haven't torn into
the code yet. However, I think it would be the devil
to maintain the glue code. It would have to be
adjusted everytime a module was modified.

But hey, anything is possible.

Cheers,

Eric

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

> I read the introduction about the paper "Cooperation
> between top-down 
> and bottom up n theorem provers"
>  you write and it seems to be a very interesting
> concept, not only for the endgames purposes.
> The point is about combining top down and bottom up
> approaches.
> That seems to be interesting, but I'm not sure to
> really understood 
> understand how it can be achived.
> One of the approach seems to be: see the aim, and
> try to reach it ( top 
> down if I understood)
> and the other one: don't care about the aim, try to
> see what you can 
> reach (bottom up if I'm not wrong)
> 
> If I understood there is two meanings to combine
> both approach. The 
> basic ideas seems to
> made the both in the same time and transmit
> information between the both 
> approaches.
> To go realisation, I would say that we keep
> startegic and tactic 
> concerns, but instead of
> have a master/slave model, we have a continuous
> discussion betwwen the 
> both modules.
> The point is it seems that what exactly I do during
> the game, I continuously
> ask me: in the local situation what can I do and 
> what startegy I must 
> apply.
> But the point is that you seems to put a hard
> communication between the both
> modules. And it appears for me to be a good point.
> As far I can understood gnugo, it has a master slave
> model,
> There is some strategic aims, to try to reach and we
> look the tactic to 
> see how
> we can achieve them. I really think that gnugo
> archictecture would 
> improve if
> it is considered as a two cooperative processes. As
> it is said in the 
> paper, the knowledge
> of each other part should  improve the global
> efficiency.
> I would say that the more the startegic module has
> knowledge of the 
> local situation,
> the more he can work efficiently, and it is the way
> that the gnugo work now.
> But the point is that, the more the tactical module
> can do well it's 
> job. And the point
> is the tactical module seems not to use informations
> gathered by 
> startegic module.
> 
> After this long mail, I need your help.
> I would like that the gnugo's developpers say me if
> there is a one way 
> communication
> betwee strategic and tactic, and Eric Parker say me
> if I precisely 
> interpreted
> the top-down/bottom-up theory
> 
> 
> Xavier
> 
> 
> _______________________________________________
> gnugo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnugo-devel
>