Re: computer-go: Evaluating positions

[Don Dailey <drd@xxxxxxxxxxxxxxxxxxxxx>]

   From: Heikki Levanto <heikki@xxxxxxxxxxxxxxxxx>
   Sender: owner-computer-go@xxxxxxxxxxxxxxxxx
   Precedence: bulk
   Reply-To: computer-go@xxxxxxxxxxxxxxxxx
   Content-Type: text/plain; charset=us-ascii
   Content-Length: 3144

   On Tue, Jun 19, 2001 at 04:18:36PM -0400, Don Dailey wrote:
   > This is interesting stuff.  
   Yes indeed!

   > Any concept we come up with is not "REAL" in an absolute sense.  These
   > are just symbolisms  our   minds use in   an  attempt  to bring   some
   > structure into our thinking about things.

   Yes, of course. And to complicate matters, most of us approach the game
   from a different direction. Some are trying to base their thinking on the
   traditional theory of go, with all of its symbolisms and approximations.
   Others try to start from general game-theoretic basics, with the symbolisms
   and aproximations that brings. Others try to start from first principles,
   and the rules of the game, and hope to get further that way...

   > Most games, in my opinion have only a single real concept, usually stated
   > by the goal of the game.

   That is of course a matter of definition. Is the the concept of life and
   death "real" in go? It is not explicitly mentioned in the rules, and one can
   imagine games where it will never need to be considered, but still I feel it
   has some "real" value in go. And how about a triple ko rule (or super-ko)?
   It may be explicitly mentioned in the rules (depending which rules you play
   by), but there can be so many games that don't even get near such a
   situation. Is this a "real" concept of the game or what?  (btw, what *is*
   the opposite of a "real" concept? fake? artificial? )

Let  me  refer to  these concepts    you mention  as definitions,  not
concepts.  In this way, we can  talk about anything  we define.  I can
also define anything I want to and then have a way  to argue about its
usefulness.  For instance let me define the "wakget" (something I just
made up out of the blue) as being the state  where you just put down a
stone that is exactly 7 x 5 intersections away from the previous stone
you laid down.  Now  I can start  writing books explaining how and why
the wakget is built into the fundamental nature of go.

If  you cannot clearly  define  it, let's call  it  an "idea."   "That
person is ugly"  is an idea.  You  cannot  define ugly.  In  chess you
might say white has the stronger pawn structure, but of course this is
an opinion and  an idea.  You can  never prove this unless  you define
pawn structure strength in some formal way.

For example,  I pulled out a Go book at random and turned to a random
page and read this passage:

  Black 97 assured the life  of the corner  group, but now White was hot
  on the attack in the centre.  He enlarged his right side in sente with
  102, then gave  chase with 104 and   106.  Although he did  not really
  hope to kill the black group, by attacking in this fashion he expected
  to solidify his own central position in sente ... etc

I am sure that you would have a really hard time defining, in a formal
way, what "giving  chase" means.  I would not  know how  to even begin
programming the concept "hot on the attack" into my Go program, but it
sounds like a great thing to have!  I really want my program to always
be "hot on the attack",  it sounds really cool.

I'm not making fun of these things.  I  know that "giving chase" seems
to have real  meaning when playing through  the games and I know  what
"hot on the attack" feels  like, when someone is doing  it to me.  But
even the expression  "attack" imputes  motives  to something that   is
purely mathmatical.

I  also feel more  comfortable   calling general principles "rules  of
thumb",  because    that   at least   admits    some   imperfection or
approximation.

So when I used the term "real" I  should have said "relevant" and when
I say "relevant" I mean this in a strictly formal way.  As an example,
having  extra material is  not relevant in  chess.  The  winner is not
decided by who  has the most  material, even though  it turns out that
this is more often the winner that the loser.   (Actually, who has the
most material has to be   strictly defined too because Chess  programs
assign different values to the pieces.)

In Go, who has the most space?  Only an omniscient entity can tell you
for sure unless  the  game is very  close   to being over.   But  your
program may attempt  to tell you by  estimating it.  This  estimate is
probably the program's best guess at the final score.



   > What we call "fundamental  principles" should be reworded for accuracy
   > to be "reality approximators" or something  like this. 

   No, I think there are levels of this. I believe there are "fundamental
   priciples" that the game is based on ("owning" points in go, available moves
   in checkers). 

I'm being a  bit of the devils advocate  here.  I agree that these are
among the fundamental principles of these  games, but in the strictest
sense, they are irrelevant!   Consider ...

Available moves in checkers doesn't matter unless  you have zero moves
available when it  is your  turn.   Owning points in  Go doesn't matter
unless the game is over.

In Go, there is at least some argument  that even considered strictly,
owning points is fundamental because you can derive a partial score in
Go, unlike  Chess   or  checkers  which  is   much more  dynamic   and
unpredictable.   I call this  "absolute ownership" which is defined as
points that you should never have to lose with best play.  Big strings
with 2 eyes are absolutely  owned and  are  part of the "real"  score.
There  is  a concept underneath this  I  call ownership   which is not
absolute but  just  as  good.   I define  this  as points   which  you
essentially own but can be traded in for an equal or greater number of
other points.  You can hold  it if you want  to but perfect play might
dictate (depending  on  the opponents  play) that you  give  it up for
equal or greater  gain elsewhere.  A lot of  points in Go do  not, and
cannot have owners until the game  progresses, but each position in Go
does have a final computable outcome (calculated by assuming best play
for both   sides.)  Of  course    it's almost impossible to   do  this
calculation.



   Then there are "derived principles", that follow logically
   from the rules (life in go). Then there are "generalized rules of thumb"
   (bulky five is not safe eye space, enclused space with two corners taken by
   enemy stones is a false eye and does not count). Then there are even more
   abstract "rules" (4-4 point does not secure territory in the corner). And so
   on to proverbs and folklore (if any player has all four corners, white wins.
   Less that eleven stones in danger, play elsewhere)

   > You can tell what is fundamental by seeing how a  good program write a
   > program.  

   This is circular reasoning. Fundamental principles should be the same if I
   write a good or bad program (even if my program is good). If my program
   depends on the phase of the moon, and happens to be a strong program
   anyway, you don't want to conclude that the moon is a fundamental principle
   of go, do you?

   > You have asked the perfectly valid question, how should we think about
   > the    approximators?   Which  things    give the  approxiamately best
   > correlation to winning the game?  How much do they overlap each other?

   This is a valid question, and a pretty hard one to answer. More importantly,
   you have raised the point that most of what we do *is* approximations. Now
   we can ask
     - approximations of what, and
     - how relevant approximations

   Interesting questions, indeed!

   -H


   -- 
   Heikki Levanto  LSD - Levanto Software Development   <heikki@xxxxxxxxxxxxxxxxx>