[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AI Methods in Go
Mousheng Xu wrote:
> At 05:00 PM 6/28/99 +0200, Patricia Hughes and David Elsdon wrote:
> >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.
>
> David,
>
> I almost agree -- I am a IGS *3k ~ *2d only, why am I still programming
> Go? HandTalk is below *3k anyway. :)
> What I am wondering about is why it's hard to get a Go program as good as
> the programmer.
The problem is "simply" that you have have to make your own knowledge of the game of
Go EXPLICIT. These is quite difficult - but not impossible. It is well known - in the
field of knowledge engineering - that experts are generally NOT very good at
articulating their own knowledge. BUT there are knowledge elicition techniques for
helping and guiding this process. ALSO knowledge representation itself is quite a
difficult, and complex area, but again, an awareness of AI/KBS techniques will
ameliorate this problem.
The hardest part of representing Go knowledge is that a lot of processing is done
within our visual systems (this is what I think). This is why we can play lightning
Go so well.Making this knowledge explicit is particularly difficult, and emulating it
could take a lot of processing power.
> A potential problem for arule based system is that you may have too many
> rules, and you don't know how to prioritize them. Resolving too many rules
> may take up a lot of computation time.
This is unlikely to be true even with thousands of rules. Many AI/KBS applications
are built using production rule systems. As a result of this, a let of effort has
gone into making these systems very powerful and very quick. There is a lot of
literature available on this subject - if you want references just ask.
Regards
David