Re: AI Methods in Go

[Patricia Hughes and David Elsdon <babel17@xxxxxxxxxx>]

I'd like to reply to a number of points raised in  Mousheng Xu's postings:

Mousheng Xu wrote:

> >3. Groups of stones - I'm finding this hard to refine enough to be useful
>
>         Your "groups" means a group of strings of the same color or both colors?

My groups are collections of strings of the same colour.

> >Basically my program is an Expert System which contains an explicit
> representation
> >of some of my knowledge of Go. As soon as I get ALL of my knowledge into
> my program
>
>         Cool. It sounds like you have a clear design, especially when you can make
> rules of strong coherence and loose coupling. You either modify your rules
> or add new rules without affecting other parts of the system.

That is the idea to start with. I expect that I will need a more sophisticated rule
architecture as my system becomes more complex. Probably something like OPS5 - a
production rule system with various ways of prioritising rules, e.g. division of rules
into rule sets which a relevant to particular situations, firing specific rules in
preference to general rules.

>         We are almost all building "expert" systems, however, in whatever language
> or with whatever method. I bet no body is trying to just use "silly" tree
> searches. :)

True, we are all building "Expert Systems", but some will be more AI/KBS oriented than
others. I am using not only AI/KBS techniques for my system architecture, but also for
my development strategy. My development strategy is to evolve my system  allowing it
to be knowledge driven. This means that I:
1. Play against my program (possibly using Many Faces)
2. Work out how to improve my program
3. Make the improvements
4. Go back to 1.

This means that my system is robust in that it is not strong in some areas, but weak
in others. This is because I always address its major weakness. It is also "shaped" by
the knowledge which I build into it, rather than being designed "top down". [I have
not expressed myself very well in this paragraph - I'll need to thing about this a bit
more !!]

I am also keen to exploit the computer's architecture - i.e. a single fast processor
with a vast amount of short term memory. This is dramatically different from my
brain's architecture - a huge number of processors but very limited short term memory.
OK, so I'm oversimplifying a bit, but the point is that the ideal "shape" of Go
knowledge for a computer will be very different from the ideal shape of Go knowledge
that people use.

>         The *** KEY *** now is to get good expert knowledge, don't you agree??? :)
>         I published my "theorems" here about 2 years ago, just tried to start a
> series of discussions on people's finding on go knowledge. But that's the
> only piece of "discussion" ever since. :) Now I am still suffering from
> lacking of abstracted go knowledge. May I make a suggestion here? -- Let's
> discuss our findings on go knowledge!

I hope that my points above are a contribution to this.

>         Here is a warning for you: Professor Chen has a team of a couple of 5d
> amateur go players as programmers, you'd better improve your go level to
> *6d to beat HandTalk. :)

I do not need to improve my Go level, although this might help. What I "will" need is
access to dan-level Go knowledge. Having a 6 dan player available would certainly be
useful at some point, but I need to do a lot more before I am ready to handle that
level of Go knowledge.

Regards

David