Re: Introduction

[David Fotland <fotland@xxxxxxxxxxxxx>]

At 07:31 AM 5/19/98 -0500, Matt Gokey wrote:
>Hello everyone,
>
>
>We all know why Go is so hard for computers and why Chess is so easy
>(comparatively), but consider this:  Imagine trying to write a chess
>program that plays using the techniques being employed for Go, that is
>primarily static evaluation using heuristics, rule sets, pattern
>matching, goal directed searches but allowing no full tree searches as
>we are restricted to in programming Go because of the search space and
>lack of a reliable position evaluation (My apologies for the exaggerated
>simplicity - the work done so far is quite impressive).  Would we get
>anywhere (i.e. master level) with this approach?  Thoughts, comments,
>anyone?

This has been tried in chess and it didn't work.  The amount of knowledge
needed
is too great, and the complexity of the code leads to lots of bugs (I know :)

One option is just to wait a few decades, when some limited form of full
width 
search will be possible for computer go.  At least full width search of local
life and death problems.

Another option is to have the computer learn interesting patterns itself.  I
think this also needs much more compute power than we have today, but it will
come.

Another option is coding up some kind of directed learning, so you can teach 
the program by pointing out bad moves and better alternatives.

I think the current approach can get to amateur 1 dan level, since there
really aren't that many patterns a 1 dan knows, but I doubt it will get to
professional strength.

David


>to handle a complex domain like Go using Go.  To develop AI to this
>degree we're going to need to start at the beginning, like nature did -
>start simply and with stepwise self refinement.  Hard coding the
>knowledge - via patterns, rules, special purpose algorithms, etc.  seems
>to be working to a degree, but I have read over and over again that the
>programs don't really seem to understand the positions and so make
>blunders that cause them to lose games.  As the size of the hard coded
>knowledge set increases, the difficulty in keeping the consistency and
>integrity of the set as a whole, I have a feeling, will increase
>exponentially.  In short, I'm of the opinion we can't likely create a
>good (dan level) Go playing program by modeling (AI or not) our
>perception (probably flawed) of human playing techniques.  What does
>everyone think?

Some people have tried to "start from simple principles, and make each
aspect of the program accurate".  Go4++ started from understanding
connectivity correctly, and has become quite strong.  Several programs
have started with life and death analysis, but that is so hard that
none of them have progressed to full programs.

I don't find that keeping the knowledge base consistent is much of a 
problem.  The key there is to have the program be able to deal with 
inconsistent knowledge and exceptions.  But I only have a few patterns.
If I had 50 thousand maybe it would be different.

  I have some high level ideas that I will introduce in my
>next post, hoping to start a discussion that together may form some
>concrete ideas for further research/work.  How about anyone else, have
>any new ideas you're willing to share?

Figure out from the start how you will deal with uncertainty.  There
will always be objects you can not analyze correctly, so have a way to
detect this condition and use it.  Adding code to deal with unknown
results later can be painful.

David
>
>
>