Re: [computer-go] Pattern matching - example play

[Don Dailey <drd@xxxxxxx>]

Hi Frank,



   From: "Frank de Groot" <frank@xxxxxxxxxxxxxxxxx>
   Date: Wed, 1 Dec 2004 11:53:02 +0100

   ----- Original Message ----- 
   To: <drd@xxxxxxxxxxxxxxxxx>; "computer-go" <computer-go@xxxxxxxxxxxxxxxxx>
   Subject: Re: [computer-go] Pattern matching - example play


   > From: "Don Dailey" <drd@xxxxxxxxxxxxxxxxx>
   > Subject: Re: [computer-go] Pattern matching - example play
   >
   >
   > > However Frank,  it seems to  me that it  should be better  to directly
   > > apply  actual  knowledge as  opposed  to  trying  to obtain  knowledge
   > > indirectly.



   Something else came to mind.
   I in fact *totally* disagree with your premisse.

   You call putting in programmer's knowledge "directly applying knowledge" and
   learning knowledge from games "indirectly applying knowledge", while in fact
   it is the other way round!

   Because when a programmer put in his knowledge, he mainly got his knowledge
   from many years of playing Go and observing Go games.

I  guess  what I'm  saying  is that  good  players  mainly gets  their
knowledge from explanations, by a teacher, by being taught.  I believe
that playing and  studying games is critical to the  success of a good
player, but in  almost all science (and I'm  considering GO a science)
lessons  by  the  individual  "students"  are learned  more  from  the
ACCUMULATION  of knowledge  and  experience passed  down to  students.
Relativity in physics  is an example.  I doubt  very many people would
have  "learned" relativity  from direct  physical observation,  it was
enough that one man did.    

I could  compare what you are  doing to trying  to learn sophisticated
science without  the benefit of an  actual teacher but  it's not quite
that  simple.  You are  trying to  teach from  GOOD examples,  which I
consider a big step higher  than learning from scratch, but still more
or less indirect.

I'm not  trying to discourage  you on this,  you are doing  some great
things here  that will  provide more insight  into these  things.  For
instance, I  admit that I could be  wrong about this (I  would like to
know if I  am) and you could make the point  that everything we learn,
even if  carefully explained to  us, is ultimately learned  by example
(the example is "spoon fed" into our imagination when explained.)  And
you might be right.  Maybe I'm arguing about nothing important here?

   Meaning, the programmer is an extra link in the chain.

Again, are you saying that a "teacher" is a waste of time?   The programmer
is a teacher.

   It's trivial to demonstrate that a programmer's learned patterns are
   inferior to directly learned patterns, as I have convinced myself I have
   done. My opinion on this:

   - A Go program that uses ONLY the rules is an example of the application of
   the application of "first level-knowledge",

   - A Go program that uses the rules AND "learned" games is an example of the
   application of "first level-knowledge" + "second level knowledge",

   - A Go program that uses the rules AND programmers' heuristics is an example
   of the application of "first level-knowledge" + "third level knowledge".

   - A Go program that uses the rules AND programmers' applied Go Dogma's
   ("truths" from books) is an example of the application of "first
   level-knowledge" + "fourth level knowledge".

   Fourth level knowledge because Go dogma's come thus into being:

   Rules --> Observed/played games --> Evolution of generally accepted
   heuristics --> Finalization of universally recognized dogma's.

   I find it risky to introduce dogma's into the system, as Go Theory (Joseki
   variations etc.) is in a state of continuous development and nobody even
   knows whether starting on Tengen is the best or not. Manually putting in
   patetrns would be naive. Better is a system that can be re-trained with the
   latest games, and it will learn the latest Joseki etc.

   Dogma's are almost always sub-optimal, and I don't see why Go would be an
   exception.


I agree  with you on  this.  A teacher  does introduce his  own biases
into the system.   What I lean towards at the moment  IS indeed a self
teaching system,  but not one  based on learning from  imperfect human
examples, which  you have to admit  are filled with  warts and biases.
Let's put  hero worship aside, even  the best players in  the world at
any game  have their idiosyncracies  and even dare I  say "weaknesses"
and in the end you would want to avoid that.

Is there any  way your system could generate it's  own games, and feed
back on  itself, gradually learning  from it's own  experiences?  This
would actually at  least introduce the possibility of  it going beyond
it's teacher.   


- Don
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/