[no subject]

[Heikki Levanto <heikki@xxxxxx>]

To: computer-go@xxxxxxxxxxxxxxxxx
Subject: Re: [Please Help] Pattern Matching Comparison
Newsgroups: lsd.compgo
Organization: LSD - Levanto Software Development
X-Newsreader: TIN [version 1.2 PL2]

Mousheng Xu (xu@xxxxxxxxxxxxxxxxx) wrote in lsd.compgo:

:     I am now working hard on pattern matching, but find myself very dumb. So I
: want some help from you guys.

Before going into the gory details, i would like to take an overall look:
Why do you want to match patterns? Where do you plan to use them? How?
Without answering these questions it must be impossible to find the "best"
method to use, just like it is impossible to agree what computer or car is
best without knowing what it will be used for.

I can see a few different ways to use patterns:

- Joseki libraries - recognising a pattern of stones (or a move sequence),
and looking up the best move or a small number of alternatives. Also, seeing
the joseki on the board, and predicting from the pattern where the enemy is
likely to move next.

- Selecting likely moves in tactical reading - Playing at the center of
three stones is often a good move to capture them.  Needs to be connected
with the tactical reading module, to see if the tesuji really works in this
situation, and also some sort of higher level thinking, if will make any
sense to capture those three stones...

- Estimating eye spaces - A bulky five shape is only one eye, but can be
made into two if I get to play first.

- Fuseki libraries - Just repeat the first few moves from the patterns, and
believe you can handle the result. Not much use if the program lacks the
skill to take advantage of the situation. (what's the point in choosing a
joseki that gives you thickness facing a weak enemy position, if you know
you can not handle the invasion, and will probably never make it)

- Generally finding a "good move". 


I think patterns do have their uses, but not as a way to find the move to
play, merely as good starting points where to start considering the next
move.  If you play anything that looks like a good pattern, you are playing
a cheap imitation of go - without the understanding of the reasons behind
the moves you can not expect good results.

For example, there may exist a nice pattern for resquing a few stones.  But
the importance of saving them depends very much on other factors, especially
if those stones cut an enemy position in two, and if both halves are weak on
their own, but would be strong if connected. This kind of information can be
coded in the patterns, but then they get quite complex. If anything, I can
see a use for patterns in the situation when the program has already decided
that capturing those three stones would be very valuable. Then a pattern
matcher can be asked what looks like the most likely move to do the job.
Unfortunately I feel that often a simple read-ahead solves the problem as
well.


These are just the thoughts of a guy who never has really programmed go,
only dreamed of it for some time. If someone can point the errors in my
thinking, I'll be happy!


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