[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
File computer-go log.199802
This digest for list has been created on Fri Feb 6 17:40:56 3898
------- THIS IS A RFC934 COMPILANT DIGEST, YOU CAN BURST IT -------
Date: Sat, 7 Feb 1998 00:32:07 +0800 (GMT)
Message-Id: <199802061632.AAA25101@xxxxxxxxxxxxxxxxx>
X-Sender: cesczx@xxxxxxxxxxxxxxxxx (Unverified)
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: computer-go@xxxxxxxxxxxxxxxxx
From: cesczx@xxxxxxxxxxxxxxxxx (Chen Zhixing)
Subject: Re: How to make a very strong Go program
X-Sequence: 3
Precedence: list
>
>to make the strongest
>possible Go program within say three years. What would you do?
>
> Martin
>
I thought it for a long time. I tend to abort Handtalk, as its algorithm
cannot make it strong enough, say, 1-dan. I want to develope a new
generation of go-program. But what is the key?
Ken Chen and Mick Reiss have done best works. In my opinion, some
principle of Go4++ are important: 1. Getting territory should be emphasized.
2. It is important to treat a great deal of knowledges instead of a few
rules. On the other hand, the move generator of Go Intellect is a good one.
Those are just the weakness of Handtalk.
I have not make a design of my new program. I must do my best to learn
the strong points of other top programs, including Go Intellect, Go4++,
MFGO, etc. Other main problems may be:
1) How to recognize and evaluate moyo? Pattern recognition may not work
in this aspect.
2) How to recognize and evaluate thickness?
I hope to get instructions from you, the members of the Computer Go
Mailing List.
Chen Zhixing
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
From: rbrown@xxxxxxxxxxxxxxxxx
Mime-Version: 1.0
Date: Mon, 16 Feb 1998 15:51:10 -0600
Message-Id: <0007A4D2.3088@xxxxxxxxxxxxxxxxx>
Subject: Re: Notation
To: computer-go@xxxxxxxxxxxxxxxxx
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
X-Sequence: 4
Precedence: list
A couple of weeks ago I posted an article titled "Notation".
Did anyone see it?
The reason I'm asking is that I haven't seen any responses. I figure
that the reason is one of three:
o My comments were so overwhelmingly insightful and correct as to
leave all of you speechless.
o My comments were facile and transparent to the point where there
was nothing to say about them. "The sky is blue."
o List distribution isn't working.
I haven't seen _any_ traffic on the list, so I hope I'm still subscribed.
This is sort of a test message to that effect, but if anyone has comments
about my previous posting, I'd like to hear those, too. Specifically, I'm
curious to what extent others have implemented the "symmetries" I mentioned
in coding their own representations of go patterns.
o Does your program recognize a joseki situation even if the moves
may have been played out of order? Tesuji? Big points?
o Does your program recognize that points on the edge of the board
are functionally equivalent to points in the middle? (Or does it
treat the edge as a special case?)
o I'm assuming that _everyone_ has a way of dealing with the eight-
fold visual symmetry. Any exceptions?
o Does your program "care" what color stones are in stored patterns,
or does it care only that they are friendly and enemy stones?
Finally, one question with has rather to do with context, and incremental
changes to context: Can your program look at an arbitrary go position and
then choose its move, or does it need to retain a history of the plays which
led to the position, in order to choose its move?
I guess I was expecting a bit more feedback, but maybe I haven't expressed my
ideas clearly enough to get it. Happy to answer any questions you may have.
Rich
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Date: Tue, 17 Feb 1998 09:51:14 +0100 (MET)
From: Jan Ramon <Jan.Ramon@xxxxxxxxxxxxxxxxx>
To: rbrown@xxxxxxxxxxxxxxxxx
Cc: computer-go@xxxxxxxxxxxxxxxxx
Subject: Re: Notation
In-Reply-To: <0007A4D2.3088@xxxxxxxxxxxxxxxxx>
Message-Id: <Pine.GSO.3.95.980217094244.1228m-100000@xxxxxxxxxxxxxxxxx>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Sequence: 5
Precedence: list
On Mon, 16 Feb 1998 rbrown@xxxxxxxxxxxxxxxxx wrote:
> A couple of weeks ago I posted an article titled "Notation".
>
> Did anyone see it?
yes
>
> The reason I'm asking is that I haven't seen any responses. I figure
> that the reason is one of three:
>
...
o i didn't have time to respond :-)
> I haven't seen _any_ traffic on the list, so I hope I'm still subscribed.
yes, i still receive your messages
>
> This is sort of a test message to that effect, but if anyone has comments
> about my previous posting, I'd like to hear those, too. Specifically, I'm
> curious to what extent others have implemented the "symmetries" I mentioned
> in coding their own representations of go patterns.
i use (slow but) "symmetric" representation:
- list of objects
[object=group or free point]
- for each object:
- coordinates of all occupied positions [free point: 1
position, group : #positions == #stones]
- pointer to all adjacent objects.
this works good, except for the 'under the stones' tesuji where you must
really look 'under the stones' :-)
> o Does your program recognize a joseki situation even if the moves
> may have been played out of order? Tesuji? Big points?
there are articles about transposition tables i'm reading.
>
> o Does your program recognize that points on the edge of the board
> are functionally equivalent to points in the middle? (Or does it
> treat the edge as a special case?)
a free point on the edge has at most 3 adjacent objects.
>
> o I'm assuming that _everyone_ has a way of dealing with the eight-
> fold visual symmetry. Any exceptions?
yes, if you see a position 'topological' as in my representation, all
symmetries including translation follow.
>
> o Does your program "care" what color stones are in stored patterns,
> or does it care only that they are friendly and enemy stones?
well, it should do i suppose. it doesn't make sense to capture your own
stones:-)
jan
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
From: rbrown@xxxxxxxxxxxxxxxxx
Mime-Version: 1.0
Date: Tue, 17 Feb 1998 11:11:12 -0600
Message-Id: <0007A93C.3088@xxxxxxxxxxxxxxxxx>
Subject: Re: Notation
To: computer-go@xxxxxxxxxxxxxxxxx
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
X-Sequence: 6
Precedence: list
This is Magnus Persson's reply to my "notation" survey. I'm forwarding it to
the list with his permission.
Thanks, Magnus, for your insightful response!
I do want to reply to some specific points, later.
Rich
______________________________ Forward Header __________________________________
Subject: Re: Notation
Author: magnus.persson@xxxxxxxxxxxxxxxxx at Internet
Date: 2/17/98 10:10 AM
> o Does your program recognize a joseki situation even if the moves
> may have been played out of order? Tesuji? Big points?
No, it is to weak to understand josekis. It think it is better to
play moves at the level it understand them. Josekis are great if you
want fool yourself that your program is better than it is.
> o Does your program recognize that points on the edge of the board
> are functionally equivalent to points in the middle? (Or does it
> treat the edge as a special case?)
Edge points are different because they are edgepoints. When my
program count the liberties of an edgestone it finds three liberties
not four. I do not understand why you think points on the edge are
functionally equivalent to points in the middle. My intuition is that
they are fundamentally different and that it is so obvious that you
might not even have to tell the program this fact explicitly. It
should be able to see the difference itself in every given position.
> o I'm assuming that _everyone_ has a way of dealing with the eight-
> fold visual symmetry. Any exceptions?
No, I do not care. Middle game fighting is a much more difficult
problem and also much more rewarding in playing strength if you come
up with a good algorithm. You can gain much more computing power if
can solve the problem with tactical independence, that is: How do you
avoid the exponential growth of move trees when the program are
unable to divide tactical goal into smaller independent subgoals. And
how do relate results from tactical search to the whole board
strategy without committing systematic errors?
> o Does your program "care" what color stones are in stored patterns,
> or does it care only that they are friendly and enemy stones?
It will not store any pattern at all until it is tactically strong
enough to prove that certain patterns safely can replace a tactical
full scale search.
If you store patterns as OneColor and OtherColor your program can
interpret as black/white or friendly/enemy or yin/yang or whatever.
It depends on the context of your pattern analyses how you are going
to interpret your patterns. Or perhaps it should be stated that you
have to decide on *how* you are going to use the patterns before you
decide what a patterns look like. Ultimately you have to analyze the
logic of go itself to understand what a pattern should be like -
otherwise you end up with something that perhaps work in 60% of the
cases but that is not enough.
> Finally, one question with has rather to do with context, and incremental
> changes to context: Can your program look at an arbitrary go position and
> then choose its move, or does it need to retain a history of the plays which
> led to the position, in order to choose its move?
The goal of my program is that it does both. It should be able to
start from any given position. It uses incremental updates of the
current analysis to gain speed, because moves in one corner
mostly does not have tactical impact in another corner, but sometimes
they do and the program should be able to handle this as well. This
is a hard problem to solve... you are warned.
> I guess I was expecting a bit more feedback, but maybe I haven't expressed my
> ideas clearly enough to get it. Happy to answer any questions you may have.
I did not answer your questions right out, but rather tried to
explain why I thought some of them was irrelevant in the quest of
a truly strong computer go program. It is nothing wrong with your
questions - I think all go programmers (including my self) have asked
these and many more like them.
The problem with solving the easy questions is that they have very
little to do with real go strength. This demands that I ask the
"right" questions, so how about this:
1) How do you make a program which never let a group be killed
unnecessarily (in the view of perhaps a one dan amateur) whatever
the state of the board. I.e a program that understand what a group is
and can evaluate its safety.
2) How do you evaluate the state of all groups on the board without
making simple errors? Most (all?) programs of today cannot handle
situations where the fate of two weak groups overlap in tactical
fighting.
Solve the above two problems with these constraints.
1) No exponential explosion in move tree generation
2) No systematic errors in situations where a 1-dan human would find
the right move easily.
No, I have not have a working program that fulfills any of my visions
above. I have a program that might someday live up to some of these
expectations at least in principle but perhaps not in playing
strength. But I would probably need at least half a year of full time
work to get a program that is not embarrassingly weak.
Good luck with your programming!
Magnus Persson
--
Magnus Persson
magnus.persson@xxxxxxxxxxxxxxxxx
http://www.docs.uu.se/~magnuspe
Department of psychology, Uppsala University
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Message-Id: <34E9C71E.CA631692@xxxxxxxxxxxxxxxxx>
Date: Tue, 17 Feb 1998 11:21:34 -0600
From: Carlisle <carlisle@xxxxxxxxxxxxxxxxx>
X-Mailer: Mozilla 4.02 [en] (Win95; I)
Mime-Version: 1.0
To: rbrown@xxxxxxxxxxxxxxxxx
Cc: computer-go@xxxxxxxxxxxxxxxxx
Subject: Re: Notation
References: <0007A4D2.3088@xxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sequence: 7
Precedence: list
rbrown@xxxxxxxxxxxxxxxxx wrote:
> A couple of weeks ago I posted an article titled "Notation".
>
> Did anyone see it?
>
> The reason I'm asking is that I haven't seen any responses. I figure
> that the reason is one of three:
>
> o My comments were so overwhelmingly insightful and correct as to
> leave all of you speechless.
>
> o My comments were facile and transparent to the point where there
> was nothing to say about them. "The sky is blue."
>
> o List distribution isn't working.
>
> I haven't seen _any_ traffic on the list, so I hope I'm still subscribed.
>
> This is sort of a test message to that effect, but if anyone has comments
> about my previous posting, I'd like to hear those, too. Specifically, I'm
> curious to what extent others have implemented the "symmetries" I mentioned
> in coding their own representations of go patterns.
>
> o Does your program recognize a joseki situation even if the moves
> may have been played out of order? Tesuji? Big points?
>
> o Does your program recognize that points on the edge of the board
> are functionally equivalent to points in the middle? (Or does it
> treat the edge as a special case?)
>
> o I'm assuming that _everyone_ has a way of dealing with the eight-
> fold visual symmetry. Any exceptions?
>
> o Does your program "care" what color stones are in stored patterns,
> or does it care only that they are friendly and enemy stones?
>
> Finally, one question with has rather to do with context, and incremental
> changes to context: Can your program look at an arbitrary go position and
> then choose its move, or does it need to retain a history of the plays which
> led to the position, in order to choose its move?
>
> I guess I was expecting a bit more feedback, but maybe I haven't expressed my
> ideas clearly enough to get it. Happy to answer any questions you may have.
>
> Rich
As a test I am sending this to both rbrown and the c-go list.
.
I have mail back to 1-29 which contains no c-go mail.
I did receive this one today 2-16-98.
There was a notice of the list being moved which may have interrupted service.
.
I am only a lurker, and can't respond to your question, but maybe this will reduce
the discouragement.
.
Carlisle
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
From: rbrown@xxxxxxxxxxxxxxxxx
Mime-Version: 1.0
Date: Tue, 17 Feb 1998 14:01:50 -0600
Message-Id: <0007AACA.3088@xxxxxxxxxxxxxxxxx>
Subject: "Notation" Survey Summary
To: computer-go@xxxxxxxxxxxxxxxxx
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
X-Sequence: 8
Precedence: list
I want to thank Chen Zhixing, Gary Boos, Heikki Levanto, Jan Ramon,
Magnus Persson, and Pieter Cuijpers for taking the time to respond
to my survey about notation.
I was pleased to receive a wide variety of responses. I felt fairly
certain going into this that not everyone sees the problem the same way
I do; the range of responses I received has borne out that assumption.
A couple of folks seemed to think I was asking the question, "How do
I do this?" Actually, I already know how _I'm_ doing it; what I was
asking was more like, "How do _you_ do this?" Which question, I feel,
can be answered to some extent anyway, without giving away any state
secrets or proprietary codes. For example, David Fotland has been
extremely generous and forthcoming with regard to this issue. (If I
remember correctly from my reading, ManyFaces matches 5x5 patterns, as
if it had played in their centers, with some points of the 5x5 being
possible don't-cares.)
The original post was titled "notation" as an attempt to convey the idea
that, for a specific behavior in which one might indulge on the go board,
it would be helpful to encode the behavior into a notation which would allow
us easily to classify that arbitrary behavior as being in some specific subset
of the set of all possible behaviors, effectively partitioning the set of all
possible behaviors into well-known classes.
Magnus Persson appears to favor an algorithmic approach to partitioning that
set, so perhaps "notation" was not the best choice for my survey's title; the
choice bespeaks the bias of my own approach. Magnus's reply reminded me that
a go program is not made up only of pattern data, but also consists, of course,
of the algorithms which operate over them. (With his permission, I've
forwarded Magnus's reply in whole to the list.)
Heikki Levanto was kind enough to reply point-by-point to my questions, but
the one statement in that reply which struck the deepest chord with me was:
>I don't need the proven optimal sequence, I need to end up with situations I
>can handle.
Yes, luckily for us go programmers, it's not necessary for the program to play
as God would. Also from that reply, a response to one of my bullets:
>> o I'm assuming that _everyone_ has a way of dealing with the eight-
>> fold visual symmetry. Any exceptions?
>I try to abstract away from it as soon as I can, and work with strings,
>groups, and other high-level structures.
To "abstract away from it" is what I was driving at, for each of the different
types of symmetry I mentioned. I think I had referred to it as "stripping out"
symmetries, but the idea is that a single expression suffices to represent all
cases which are equivalent with respect to a particular type of symmetry.
Jan Ramon posted his response to the list; thanks Jan!
Pieter Cuijpers sent me this:
>My idea involves filtering of a set of moves
>starting with all legal moves in a situation.
>The strong point of this aproach is that the
>quality of the filters involved can be measured
>by comparing the output set with the move a
>professional would have made.
>You can this way check the quality of your
>program by replaying professional games.
I wholeheartedly agree with this approach, and was mildly surprised to
hear again from Magnus only moments after reading it:
>In my program each
>empty point is evaluated as if each player tried to play there, [...]
Me: "Set of all possible behaviors..."
Pieter: "All legal moves..."
Magnus: "Each empty point..."
It would seem that whether one's approach is based on stored patterns or
on algorithmic filtering, the goal is to filter out all the bad plays as
bad, and recognize the potentially good ones as good. Perhaps that all goes
without saying. I find it interesting that Pieter, Magnus, and myself all
have our programs evaluate each empty point as if each player tried to play
there, so the real common idea here seems to be "evaluation function" rather
than either "algorithms" or my naive "notation". [New question: Anyone brave
enough to do lookahead? Is it alpha-beta minimax? Proof numbers? Something
else?]
One thing that everyone did agree on is that this problem is really hard.
But you already knew that. :)
Future replies to the list, please.
Rich
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
From: rbrown@xxxxxxxxxxxxxxxxx
Mime-Version: 1.0
Date: Tue, 17 Feb 1998 16:25:36 -0600
Message-Id: <0007AC49.3088@xxxxxxxxxxxxxxxxx>
Subject: Corner, Edge, Middle
To: computer-go@xxxxxxxxxxxxxxxxx
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
X-Sequence: 9
Precedence: list
I asked:
> o Does your program recognize that points on the edge of the board
> are functionally equivalent to points in the middle? (Or does it
> treat the edge as a special case?)
Magnus Persson responded:
>Edge points are different because they are edgepoints. When my
>program count the liberties of an edgestone it finds three liberties
>not four. I do not understand why you think points on the edge are
>functionally equivalent to points in the middle. My intuition is that
>they are fundamentally different and that it is so obvious that you
>might not even have to tell the program this fact explicitly. It
>should be able to see the difference itself in every given position.
I'll try to illustrate by way of examples what I mean by the "functional
equivalence" of corner, edge, and center points. Despite what may _seem_
intuitively obvious, I do not agree that points in the corner or on the
edge are really so very different from those in center. I _do_ agree
that a program should be able to detect any difference in behaviors, when
behaviors _are_ truly different from one another.
Let's begin with a pathological case, that of filling one's own eye in a
living group. Consider a two-eyed group somewhere in the middle of the board,
one on the edge, and a similar one, say, in the lower left corner. For the
sake of clarity, we'll assume that none of the three groups has any external
liberties, each being tightly surrounded by enemy stones. Each of the three
groups has exactly two liberties, at the points marked 'x'.
|
O O O O O O O O O O |O O O O
O x O x O O x O x O |x O x O
O O O O ----------- ----------
Middle. Edge. Corner.
Now, each of the points marked 'x' are vacant points, eyes in fact. The
pathological behavior of filling any of these is really identical. It doesn't
matter one whit that the eyes themselves may be on the first line. Clearly,
the behavior of playing on any of the points marked 'x' is equivalent to that
of playing on any of the other points marked 'x'. This is so, regardless of
its locaction in the middle, at the edge, or in the corner. (We're unconcerned
here that a different _number_ of stones would die; what we are interested in
is the similarity of _behavior_ in each case.)
Here's another example, involving a placement inside a flower-six
("rabbity-six") to kill. (Again, assume no external liberties.) Suppose the
foe were to occupy the central point of any of the six-point vacant areas in
these three diagrams:
|
O O O O O O | O O O
O O + O O O O + O O | O + O O
O + + + O O + + + O | + + + O
O + + O O O + + O O | + + O O
O O O ----------- -----------
Middle. Edge. Corner.
Isn't the foe's behavior equivalent in each case, killing the group? Likewise,
if 'O' himself plays on the center of any of the six-point areas shown, isn't
the function of the play equivalent? Does it not make each group survive?
This, then, is the function of the move, regardless of its position in the
center, on the edge, or at the corner.
In fact, any of the five "wrong" moves in the above diagrams is also equivalent
to its counterpart in the other locations. Let's consider the vacant points in
the three flower-sixes above:
a a a
b c d b c d b c d
e f e f e f
The points marked 'c' in each flower-six are functionally equivalent behaviors,
as we showed above. When played by the foe, they kill, and when played by the
friend, they cause the group to survive.
Given the context of the surrounding stones, the points marked 'c' also happen
to be prime examples of _vital_ points, but that's not the main issue here. We
are rather more interested in the general description of behavior in go, both
good and bad.
It is further true that even the "wrong" moves share an equivalence relation
with each other: Not only are all three points marked 'a' (above) equivalent to
each other, they are also equivalent to all points marked 'd' (because of the
mirror-image translation symmetry). Similar remarks apply to the points marked
'b' and 'f', all of which are equivalent to one another, without regard to
their actual location on the board. As for the three points marked 'e', they
may be right in the corner of the board, or on an edge, or in the middle, but
that fact is an irrelevant symmetry about which we would prefer not to care.
An equivalence relation is one that is transitive, reflexive, and... what's
the other word? Anyway, [where '~' is read "is equivalent to"] an equivalence
relation must satisfy the following conditions:
A ~ A .
If A ~ B then B ~ A .
If A ~ B and B ~ C , then A ~ C .
I have tried to show the following by means of the examples above:
First example: The six plays at points marked 'x'are equivalent
behaviors, without regard to their actual location in the middle,
on the edge, or at the corner. (Note that friend _only_ may play
on these six: Suicide is illegal, but filling your own eyes is
merely stupid.)
Second example: The three plays by friend at points marked 'c' are
equivalent behaviors, without regard to their actual location in the
middle, on the edge, or at the corner. Similarly, a play at any of
these three points by the foe is equivalent to his play at either of
the remaining two. Further, the six points marked 'a' and 'd' are
equivalent to one another, for a given player to behave that way. The
six points marked 'b' and 'f' are likewise equivalent to one another.
The three points marked 'e' also represent three equivalent behaviors,
should White choose to play on any of them. Ditto Black.
And all of these things are true, _regardless_ of where on the board we happen
to find a particular behavior. There is nothing special about the edge.
Harking back to my obsession with "notation", allow me to borrow some term-
inology from group theory. We can perform the operation of rotation by 90
degrees (just what it sounds like), or the operation of translation of 180
degrees (flipping the board over) and the situtation on the board remains the
same. (Provided that the stones didn't all fall off when we flipped the board
over, that is! All right, they're magic stones, yeah, that's it, and they
passed right through the board, yeah, like cream rising to the top! Yeah!)
In all seriousness: Just as the eight equivalent isomers of a go position are
said to "form a _group_ with respect to the _operations_ of translation and
rotation" (where translation and rotation mean that we don't care how we have
oriented the board), so also do equivalent behaviors (as in the examples above)
"form a _group_ with respect to the _operation_ of relocation" (where relocation
means that we don't care where on the board the behavior occurs).
The keywords _group_ and _operation_ have very specific meanings in group
theory. Discovering what those are, is left as an exercise for the reader.
[I've always wanted to say that.]
More later.
Rich
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Message-Id: <l03020910b10fc430aec3@[10.0.2.15]>
In-Reply-To: <0007AC49.3088@xxxxxxxxxxxxxxxxx>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 17 Feb 1998 14:53:49 -0800
To: rbrown@xxxxxxxxxxxxxxxxx, computer-go@xxxxxxxxxxxxxxxxx
From: Dave Dyer <ddyer@xxxxxxxxxxxxxxxxx>
Subject: Re: Corner, Edge, Middle
X-Sequence: 10
Precedence: list
w.r.t. edge equivalence; you're overlooking the most obvious conterexample,
which is bent four (dead in the corner, alive anywhere else).
My shape outcome library is segregated for center,side and corner placement,
and while I can't recall any positions where the side is different from center,
there are *many* positions where corner placement is different from center.
Generally speaking, they involve the shortage of liberties of a stone placed
in or near the corner.
http://www.andromeda.com/people/ddyer/go/shape-library.html
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Date: Tue, 17 Feb 1998 15:19:17 -0800 (PST)
From: William Shubert <wms@xxxxxxxxxxxxxxxxx>
Message-Id: <199802172319.PAA28440@xxxxxxxxxxxxxxxxx>
To: computer-go@xxxxxxxxxxxxxxxxx, ddyer@xxxxxxxxxxxxxxxxx, rbrown@xxxxxxxxxxxxxxxxx
Subject: Re: Corner, Edge, Middle
X-Sequence: 11
Precedence: list
Dave Dyer <ddyer@xxxxxxxxxxxxxxxxx>:
>My shape outcome library is segregated for center,side and corner placement,
>and while I can't recall any positions where the side is different from center,
>there are *many* positions where corner placement is different from center.
Here's one where edge and center are different:
# # # # # # # # # #
# . O . # # . O . #
# O . . # # O . . #
# # # # # -------------
Black (#) lives Black (#) dies
(Both assume that it is #'s move and there are no outside liberties).
The edge and center are definitely different.
--
Bill Shubert (wms@xxxxxxxxxxxxxxxxx)
http://www.hevanet.com/wms/
(PS - ddyer, sorry, I think I sent you two copies of this).
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Date: Wed, 18 Feb 1998 01:24:33 +0100 (MET)
Message-Id: <199802180024.BAA18415@xxxxxxxxxxxxxxxxx>
X-Sender: darren@xxxxxxxxxxxxxxxxx
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: computer-go@xxxxxxxxxxxxxxxxx
From: Darren Cook <darren@xxxxxxxxxxxxxxxxx>
Subject: *For Moderator*
X-Sequence: 12
Precedence: list
I'm not sure if this list is still moderated or not, so my apologies if this
ends up on the list.
Can we have the emails contain this header:
Reply-to: computer-go@xxxxxxxxxxxxxxxxx
The mailing list used to work this way, and it prevents all that messing
about having to ask people for permission to forward their comments when
they intended them to go the list anyway.
Thanks for your hard work,
Darren
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Date: Wed, 18 Feb 1998 09:57:04 +0100 (MET)
From: Jan Ramon <Jan.Ramon@xxxxxxxxxxxxxxxxx>
To: rbrown@xxxxxxxxxxxxxxxxx
Cc: computer-go@xxxxxxxxxxxxxxxxx
Subject: Re: Corner, Edge, Middle
In-Reply-To: <0007AC49.3088@xxxxxxxxxxxxxxxxx>
Message-Id: <Pine.GSO.3.95.980218094800.1228t-100000@xxxxxxxxxxxxxxxxx>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Sequence: 13
Precedence: list
On Tue, 17 Feb 1998 rbrown@xxxxxxxxxxxxxxxxx wrote:
...
> Here's another example, involving a placement inside a flower-six
> ("rabbity-six") to kill. (Again, assume no external liberties.) Suppose the
> foe were to occupy the central point of any of the six-point vacant areas in
> these three diagrams:
>
> |
> O O O O O O | O O O
> O O + O O O O + O O | O + O O
> O + + + O O + + + O | + + + O
> O a + O O O a + O O | a + O O
> O O O ----------- -----------
>
> Middle. Edge. Corner.
>
> Isn't the foe's behavior equivalent in each case, killing the group? Likewise,
> if 'O' himself plays on the center of any of the six-point areas shown, isn't
> the function of the play equivalent? Does it not make each group survive?
> This, then, is the function of the move, regardless of its position in the
> center, on the edge, or at the corner.
>
> Given the context of the surrounding stones, the points marked 'c' also happen
> to be prime examples of _vital_ points, but that's not the main issue here. We
> are rather more interested in the general description of behavior in go, both
> good and bad.
You can't be certain that the behavior is equivalent in all cases. In my
opinion this is caused by the fact that e.g. the position 'a' marked in
your pattern, is not in all cases a liberty of the group. This doens't
matter in all cases, but certainly in the following:
OOOOO ------
Oab.O |ab.O
O.OOO |.OOO
OOO |OO (a,b and . are empty, O is stone)
because the point 'a' in the corner case is not a liberty of the group, it
is possible to start a ko (at 'b')
nevertheless, i think the general idea is good.
jan
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Date: Wed, 18 Feb 1998 13:46:28 +0000 (GMT)
From: Tim Hunt <T.J.Hunt@xxxxxxxxxxxxxxxxx>
X-Sender: tjh1000@xxxxxxxxxxxxxxxxx
To: computer-go@xxxxxxxxxxxxxxxxx
Subject: Re: "Notation" Survey Summary
In-Reply-To: <0007AACA.3088@xxxxxxxxxxxxxxxxx>
Message-Id: <Pine.SGI.3.91.980218134247.2348B-100000@xxxxxxxxxxxxxxxxx>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Sequence: 14
Precedence: list
On Tue, 17 Feb 1998 rbrown@xxxxxxxxxxxxxxxxx wrote:
> Heikki Levanto was kind enough to reply point-by-point to my questions, but
> the one statement in that reply which struck the deepest chord with me was:
>
> >I don't need the proven optimal sequence, I need to end up with situations I
> >can handle.
It strikes me that could be something that a professional player would
say. Wow, perhaps there is hope for these computer programs yet!
Tim Hunt.
.. .. .. .. .. .. .. ..
Tim Hunt, 63 Panton Street, Cambridge, CB2 1HL, UK. Tel +44 1223 500769
or DAMTP, Silver Street, Cambridge, CB3 9EW, UK.
.. .. .. .. .. .. .. ..
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
From: rbrown@xxxxxxxxxxxxxxxxx
Mime-Version: 1.0
Date: Wed, 18 Feb 1998 10:05:01 -0600
Message-Id: <0007B01B.3088@xxxxxxxxxxxxxxxxx>
Subject: Re: Corner, Edge, Middle
To: computer-go@xxxxxxxxxxxxxxxxx
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
X-Sequence: 15
Precedence: list
Several folks found counterexamples to the conjecture that points along the
edges and at the corners are equivalent to those in the center. Excellent work!
Thanks to Dave Dyer and Jan Ramon for pointing out the bent-four and other
corner exceptions, and special thanks to Bill Schubert for finding an exception
along the edge.
However, my deepest gratitude does to Mitch Gunzler who wrote:
>I think I understand what you mean. Any difference should "fall out" from
>analysis, nt be imposed by the structure of the code from the start.
Yes, what I was getting at is that the _notation_ (my obsession rears its
ugly head once more) used for identifying behaviors need not encode the
flags "this is an edge point" or "this is a corner point". But of course,
as I wrote: "I _do_ agree that a program should be able to detect any
difference in behaviors, when behaviors _are_ truly different from one
another." When in doubt, read it out.
To summarize my ramblings, this is all about finding symmetries of various
sorts, and stripping them out of the notation for a behavior. This idea
of throwing away useless or redundant information when representing a
pattern is actually a precursory step in what's called "Syntactic Pattern
Recognition". That's a whole 'nother can of worms, which I will probably
open, right here in this forum, at another time. Stay tuned.
Now I have a question for Mitch, about his life-and-death analyser.
>Here's an idea for an analysis that doesn't give a priori special status
>to locations on a side or corner:
>
>Let a Group be any set of stones of one color;
>
>Let each empty area on the board bordered by no stones other than members
>of the group, and in which no enemy stones can live, be called Eyes;
>
>Then a Group is Alive iff it has at least two Eyes adjacent next to each
>of it's stones.
>("Surrounded" may need work to define, "enemy stones can't live" certainly
>does.)
What is the meaning of "bordered by no stones other than members of the group"?
If there are foe stones inside my territory, they are certainly adjacent to it.
Do they "border" it? How do you make the jump from "adjacent" to "bordered" so
that the analysis does not fail when there are foe stones within? That is,
don't you need to define "bordered" as some sort of contiguous loop (give or
take some hanging connections) around the territory?
Is the notion of being bordered perhaps a natural result of the topological
approach, like identifying a doughnut as being equivalent to a coffee cup?
Anywyay, I suppose that if the "enemy stones can't live" condition is
satisfied, you don't even have to notice the contiguous loop! But isn't
that condition itself a bit circular? A group is said to be "alive" iff ...
foe stones inside its eyes are not able to become "alive". Hmmm.
>Then a Group is Alive iff it has at least two Eyes adjacent next to each
>of it's stones.
Not every stone in the group needs to be adjacent to an Eye. For example, in a
dango shape, one or more of the stones might be adjacent only to other stones,
and not adjacent to any vacant space.
In any case, a program must of course be able to detect the status of groups.
Some groups' stati surely are easier than others' to detect!
Rich
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
From: rbrown@xxxxxxxxxxxxxxxxx
Mime-Version: 1.0
Date: Thu, 19 Feb 1998 09:11:09 -0600
Message-Id: <0007B6B5.3088@xxxxxxxxxxxxxxxxx>
Subject: Re: Corner, Edge, Middle
To: computer-go@xxxxxxxxxxxxxxxxx
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
X-Sequence: 16
Precedence: list
I'm forwarding the message below on behalf of its author, Paul Leonard, who was
unable to post to the list.
I also received a response from Mitch to my question about the life-and-death
analysis, and a response to the survey from Bruce Wilcox. But, without their
say-so, I feel funny about forwarding those messages to the list. I'd be glad
to do so if Mitch or Bruce did not save a copy, and the messages were indeed
intended for the whole list.
I'm casting a vote in favor of configuring the list so that replies go to the
whole list, by default. If this is a majordomo list, this can be acheived by
chaning the "reply-to" line of the file "computer-go.config" to read:
reply_to = computer-go
Rich
______________________________ Forward Header __________________________________
Subject: Re: Corner, Edge, Middle
Author: "P.J.Leonard" <P.J.Leonard@xxxxxxxxxxxxxxxxx> at Internet
Date: 2/19/98 11:18 AM
Ooops I do not seem to be able to post to computer-go . . . but I get
mail !!!!
Here is what I what I sent.
Systeme de Multi-Postage Automatique wrote:
>
> You have tried to send a message to a list which is private without being a
> subscriber of this list. For your convenience your original message is being
> sent back to you.
>
> Your message:
>
> Received: from pat.bath.ac.uk (qmailr@xxxxxxxxxxxxxxxxx [138.38.32.2]) by
> itesec.hsc.fr (8.8.8/8.8.5/itesec-1.10-nospam) with SMTP id KAA15029 for
> <computer-go@xxxxxxxxxxxxxxxxx>; Thu, 19 Feb 1998 10:56:14 +0100 (MET)
> Received: (qmail 4984 invoked from network); 19 Feb 1998 09:55:35 -0000
> Received: from solomon.bath.ac.uk (HELO bath.ac.uk) (mmdf@xxxxxxxxxxxxxxxxx) by
> pat.bath.ac.uk with SMTP; 19 Feb 1998 09:55:35 -0000
> Received: from tobi.bath.ac.uk by solomon.bath.ac.uk id aa13423;
> 19 Feb 98 9:55 GMT
> Sender: pjl@xxxxxxxxxxxxxxxxx
> Message-Id: <34EC0177.237C@xxxxxxxxxxxxxxxxx>
> Date: Thu, 19 Feb 1998 09:55:03 +0000
> From: "P.J.Leonard" <P.J.Leonard@xxxxxxxxxxxxxxxxx>
> Organization: Applied Electromagnetic Research Centre
> X-Mailer: Mozilla 3.0 (X11; I; OSF1 V2.0 alpha)
> Mime-Version: 1.0
> To: computer-go@xxxxxxxxxxxxxxxxx
> Subject: Re: Corner, Edge, Middle
> References: <0007B01B.3088@xxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> rbrown@xxxxxxxxxxxxxxxxx wrote:
>
> > Is the notion of being bordered perhaps a natural result of the topological
> > approach, like identifying a doughnut as being equivalent to a coffee cup?
>
> Yes. In my program I use the winding number of a boundary iterator to
> classify the bourder an area. For example
> eye space is the inverse of the set of stones of a color.
>
> I seed the iterator with an adjacent point and scan around the boundary
> of the area by keeping the area to my left. If you imagine a vector
> pointing normal to the area this will rotate as you proceed around the
> area.
>
> If I get back to where I started then the vector will have either
> turned 1 turn clockwise OR anticlockwise. This represents an interior
> area (eye space) or an exterior area.
>
> If a area touches the side the boundary iterator will terminate at
> this edge. The winding number (in quarter turns) of the vector tells me
> if the area is
> on a side or is in the corner etc.
>
> I guess I could have used the outer boundary of the board as part of
> the boundary for an area
> but the code would have gotten very ugly. Terminating at the edge is
> quite natural.
>
> This scheme was intended to be used to identify and classify the
> potetial eye
> spaces. But I gave up due to a divergence of the program away from the
> way
> I think I think.
>
> Cheers Paul.
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
X-Sender: siabod@xxxxxxxxxxxxxxxxx (Unverified)
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: computer-go@xxxxxxxxxxxxxxxxx
From: siabod@xxxxxxxxxxxxxxxxx (siabod)
Message-Id: <E0y5vgK-0002vA-00@xxxxxxxxxxxxxxxxx>
Date: Fri, 20 Feb 1998 16:52:12 +0000
X-Sequence: 17
Precedence: list
Hi there
I have a fairly simple question :
Could anyone help me to find this DLL used at FOST97 (i think)
for modem connections ?
Many thanks in advance
Jeroen Brilleman
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Date: Fri, 20 Feb 1998 16:08:00 +0100
Message-Id: <199802201508.QAA09252@xxxxxxxxxxxxxxxxx>
From: Jean-loup Gailly <jloup@xxxxxxxxxxxxxxxxx>
To: computer-go@xxxxxxxxxxxxxxxxx
Subject: archive of the computer-go mailing list
Reply-To: Jean-loup Gailly <jloup@xxxxxxxxxxxxxxxxx>
X-Sequence: 18
Precedence: list
I have put an archive of this mailing list from July 3rd 1997
to Feb 17th 1998 in ftp://ftp.nuri.net/Go/comp/compgo-mail-13.Z
The archives from the beginning to July 1997 are in compgo-mail-1.Z to
compgo-mail-12.Z. A search engine for these archives is available at
http://www.psy.uq.edu.au/~jay/go/cgm-srch.html thanks to Jay Burmeister.
An automatic archive of recent messages sent to the list is maintained
by the list processor; an index of the archives can be obtained by
sending the message "index computer-go" (without the quotes) in the
body of a message to <listproc@xxxxxxxxxxxxxxxxx>.
The messages in this archive have been sorted by thread whenever possible,
and the long duplicated quotes of earlier messages have been removed,
since they appear just above in this archive. Paragraphs with very long
lines (>80 characters) have been reformatted. The unedited messages are
still available in the automatic archive maintained by the list processor.
To leave the mailing list, send the message "unsubscribe computer-go"
(without the quotes) to <computer-go-request@xxxxxxxxxxxxxxxxx>. Do not send
your message to the whole list. Thanks.
Messages for the list should be sent to computer-go@xxxxxxxxxxxxxxxxx
More information on the computer-go mailing list is available at
http://www.hsc.fr/computer-go/
Jean-loup
http://www.teaser.fr/~jlgailly/#go
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Message-Id: <199802201952.OAA18739@xxxxxxxxxxxxxxxxx>
X-Sender: joeguy@xxxxxxxxxxxxxxxxx (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Demo
Date: Fri, 20 Feb 1998 14:51:43 -0500
To: computer-go@xxxxxxxxxxxxxxxxx
From: Joe Guy <joeguy@xxxxxxxxxxxxxxxxx>
Subject: Fwd: Sparse memory model
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sequence: 19
Precedence: list
>Date: Fri, 20 Feb 1998 09:19:00 +0100 (MET)
>From: Pentti Kanerva <kanerva@xxxxxxxxxxxxxxxxx>
>To: joeguy@xxxxxxxxxxxxxxxxx
>Subject: Sparse memory model
>
>> Hi - is the paper on your sparse memory model available anywhere?
>
>Lo (and behold) - there is no paper but there is a book on it, and
>a chapter in another book.
>
>Kanerva, P. Sparse Distributed Memory. Cambridge, Mass.: MIT Press, 1988.
>
>Kanerva, P. "Sparse distributed memory and related models."
> In M.H. Hassoun (ed.), Associative Neural Memories: Theory and
> Implementation, pp. 50-76. New York: Oxford University Press, 1993.
>
>Any chance of your getting hold of either? Good luck. - Pentti Kanerva
>
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Message-Id: <3.0.5.32.19980221111426.007bde00@xxxxxxxxxxxxxxxxx>
X-Sender: fotland@xxxxxxxxxxxxxxxxx
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Sat, 21 Feb 1998 11:14:26 -0800
To: rbrown@xxxxxxxxxxxxxxxxx, computer-go@xxxxxxxxxxxxxxxxx
From: David Fotland <fotland@xxxxxxxxxxxxxxxxx>
Subject: Re: Notation
In-Reply-To: <0007A4D2.3088@xxxxxxxxxxxxxxxxx>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sequence: 20
Precedence: list
At 03:51 PM 2/16/98 -0600, rbrown@xxxxxxxxxxxxxxxxx wrote:
>A couple of weeks ago I posted an article titled "Notation".
>
>Did anyone see it?
I didn't see it.
For The Many Faces of Go:
>
> o Does your program recognize a joseki situation even if the moves
> may have been played out of order?
No. The joseki library is just a big directed acyclic graph. The
graph includes most of the common transpositions in the first few
moves though, including some with tenuki and color reversal (like
5-3, then 3-4, then tenuki, then some 3-4 pincer variation).
> Tesuji?
Some tesuji are recognized by the pattern library, with no transposition
knowledge. Tesuji for capture of groups with 4 of fewer liberties are
solved by the tactician, so it will find solutions with transpositions.
> Big points?
Big pints are found sometimes with patterns, and sometimes by special case
code. Don't know what you mean by transposition here, since they are
usually just big singel gote moves, not sequences.
>
> o Does your program recognize that points on the edge of the board
> are functionally equivalent to points in the middle? (Or does it
> treat the edge as a special case?)
The edge is not the same as the middle, so it does not treat them the
same. For secure territory evaluation it acts as if the first 3 or 4
lines are reflected off the edge of the board. But for tactics it knows
where the edge is and for example knows that it is better to force the
opponent's group towards the edge than towards the center.
>
> o I'm assuming that _everyone_ has a way of dealing with the eight-
> fold visual symmetry. Any exceptions?
The pattern matcher looks at all 8 orientations, and color reversal as
well for those patterns that don't include an edge or corner.
>
> o Does your program "care" what color stones are in stored
patterns,
> or does it care only that they are friendly and enemy stones?
The patterns are matched with colors specified and colors reversed. Each
pattern suggests a tree of moves for each color.
>
>Finally, one question with has rather to do with context, and incremental
>changes to context: Can your program look at an arbitrary go position and
>then choose its move, or does it need to retain a history of the plays which
>led to the position, in order to choose its move?
Arbitrary position, but some of the board information is incremental, and
is created stone by stone as the arbitrary position is being set up.
David Fotland
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Message-Id: <3.0.5.32.19980221112908.007e4970@xxxxxxxxxxxxxxxxx>
X-Sender: fotland@xxxxxxxxxxxxxxxxx
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Sat, 21 Feb 1998 11:29:08 -0800
To: computer-go@xxxxxxxxxxxxxxxxx
From: David Fotland <fotland@xxxxxxxxxxxxxxxxx>
Subject: Re: Notation
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sequence: 21
Precedence: list
>
>This is Magnus Persson's reply to my "notation" survey. I'm forwarding it to
>the list with his permission.
>The problem with solving the easy questions is that they have very
>little to do with real go strength. This demands that I ask the
>"right" questions, so how about this:
>
>1) How do you make a program which never let a group be killed
>unnecessarily (in the view of perhaps a one dan amateur) whatever
>the state of the board. I.e a program that understand what a group is
>and can evaluate its safety.
An important extra condition is "without making very many
unneccessary safety moves". It's easy to make a program
that never leaves a weak group on the board. Just make lots
of extra moves in close cases rather than reading. This approach
leads to a very weak program of course, since it will waste lots
of moves.
Accurately evaluating group strength at dan level for non-enclosed,
middlegame fighting groups, considering running moves, double
attacks, etc. is extremely difficult.
>2) How do you evaluate the state of all groups on the board without
>making simple errors? Most (all?) programs of today cannot handle
>situations where the fate of two weak groups overlap in tactical
>fighting.
I'd rather say that strong programs can handle many cases of overlapping
groups in fights, but none can handle most cases. I think all programs
will find double atari for example.
David Fotland
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Message-Id: <3.0.5.32.19980221114248.007f0420@xxxxxxxxxxxxxxxxx>
X-Sender: fotland@xxxxxxxxxxxxxxxxx
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Sat, 21 Feb 1998 11:42:48 -0800
To: computer-go@xxxxxxxxxxxxxxxxx
From: David Fotland <fotland@xxxxxxxxxxxxxxxxx>
Subject: "Notation" Survey Summary
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sequence: 22
Precedence: list
>From: rbrown@xxxxxxxxxxxxxxxxx
>Date: Tue, 17 Feb 1998 14:01:50 -0600
>Subject: "Notation" Survey Summary
>To: computer-go@xxxxxxxxxxxxxxxxx
>X-Sequence: 8
>
>extremely generous and forthcoming with regard to this issue. (If I
>remember correctly from my reading, ManyFaces matches 5x5 patterns, as
>if it had played in their centers, with some points of the 5x5 being
>possible don't-cares.)
8x8 patterns, usually with no regard to the last move, with some points
being don't cares of several varieties. But pattern matching is only a
small part of evaluation and move generation. Many moves are made for
tactical
or life and death reasons, which are not driven by pattern matching. Patterns
are used mostly to suggest good quiet moves. Goliath uses 5x5 patterns, with
a provision for 5x10. I've seen programs that use 11x11 patterns. It seems
to follow from sizes that fit in 32, 64, or 128 bits easily.
>
>Heikki Levanto was kind enough to reply point-by-point to my questions, but
>the one statement in that reply which struck the deepest chord with me was:
>
>>I don't need the proven optimal sequence, I need to end up with situations I
>>can handle.
Yes! Sometimes knowing the optimal sequence is bad, since it leaves the
program
in a position it doesn't understand so it makes an extra defensive move for
example. Simple, conservative sequences are usually better.
>
>>My idea involves filtering of a set of moves
>>starting with all legal moves in a situation.
>>The strong point of this aproach is that the
>>quality of the filters involved can be measured
>>by comparing the output set with the move a
>>professional would have made.
>>You can this way check the quality of your
>>program by replaying professional games.
I prefer to only generate cantidate moves that have a purpose the
program understands, rather than generate all and filter out the bad ones.
I've tried it both ways, and this works better for me.
>
>It would seem that whether one's approach is based on stored patterns or
>on algorithmic filtering, the goal is to filter out all the bad plays as
>bad, and recognize the potentially good ones as good. Perhaps that all goes
>without saying. I find it interesting that Pieter, Magnus, and myself all
>have our programs evaluate each empty point as if each player tried to play
>there, so the real common idea here seems to be "evaluation function" rather
>than either "algorithms" or my naive "notation". [New question: Anyone
brave
>enough to do lookahead? Is it alpha-beta minimax? Proof numbers? Something
>else?]
Just using an evaluation function is very hard. Go4++ is the only I know
that does it successfully. The problem is that many moves in go have
almost the
same value. Most programs evaluate moves rather than positions, or do some
combination.
you can't play go without reading. Of course you have to do lookahead. Most
programs have several sets of lookahead routines. For local string
capture, for
life and death reading, for whole board evaluation.
In Many Faces of Go, for string tactics, I use depth first alpha-beta, with
allowed branching factor high at the root, and decreasing toward the leaves.
For life and death I use a best-first algorithm, that allows learning from one
part of the search to affect move ordering in other parts of the search.
Evaluating
life and death endpoints is so slow that there is plenty of time available to
reorder nodes, choose which leaf to expand, etc.
For full board lookahead, I use depth first alpha-beta again.
David Fotland
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Date: Sun, 22 Feb 1998 23:34:13 +0800 (GMT)
Message-Id: <199802221534.XAA28176@xxxxxxxxxxxxxxxxx>
X-Sender: cesczx@xxxxxxxxxxxxxxxxx
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: computer-go@xxxxxxxxxxxxxxxxx
From: cesczx@xxxxxxxxxxxxxxxxx (Chen Zhixing)
Subject: Re: "Notation" Survey Summary
X-Sequence: 23
Precedence: list
Rich wrote:
> Anyone brave enough to do lookahead? Is it alpha-beta minimax? Proof
>numbers? Something else?
>
David Fotland replied:
>Just using an evaluation function is very hard. Go4++ is the only I know
>that does it successfully.
Most programs are using look ahead for move selection, I think.
Go4++ also uses lookahead but shallowly. Its 1996 version shows the
course of its lookahead on the board.
Star of Poland, at lease in its earlier versions, seems without lookahead.
Handtalk up to 1994 did not use lookahead for move selection. It has
used alpha-beta since 1995, getting a little progress in strength.
Wulu, a participant of 1996 Ing Cup, did not use lookahead at all.
Lookahead used in Wulu in 1997, but it did not participate any tournament
last year.
In my opinion, Lookahead is necessary, but should not be the main
approach. Goe program should include huge quantity of knowledge.
Chen Zhixing
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Date: Sun, 22 Feb 1998 23:44:19 +0800 (GMT)
Message-Id: <199802221544.XAA28241@xxxxxxxxxxxxxxxxx>
X-Sender: cesczx@xxxxxxxxxxxxxxxxx
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: computer-go@xxxxxxxxxxxxxxxxx
From: cesczx@xxxxxxxxxxxxxxxxx (Chen Zhixing)
X-Sequence: 24
Precedence: list
Dear Sir,
I found there is a difference after moving of the Mailing List. If I
click on the 'reply' item to make a reply to a mail from the List, the mail
will not be sent to the address 'computer-go@xxxxxxxxxxxxxxxxx', but sent to the
address of the writer of the original mail, so that it cannot be sent to all
member of the Mailing List. Can this be improved?
Sincerely,
Chen Zhixing
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
X-Sender: siabod@xxxxxxxxxxxxxxxxx (Unverified)
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: computer-go@xxxxxxxxxxxxxxxxx
From: siabod@xxxxxxxxxxxxxxxxx (siabod)
Subject: Thanks
Message-Id: <E0y7Gla-0002ud-00@xxxxxxxxxxxxxxxxx>
Date: Tue, 24 Feb 1998 09:35:10 +0000
Reply-To: computer-go@
X-Sequence: 25
Precedence: list
Many and great thanks to all you out there helping me
out with finding the DLL
Greetings Jeroen Brilleman
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Message-Id: <199802240849.JAA18252@xxxxxxxxxxxxxxxxx>
From: "Magnus Persson" <magnus.persson@xxxxxxxxxxxxxxxxx>
To: computer-go@xxxxxxxxxxxxxxxxx
Date: Tue, 24 Feb 1998 09:45:46 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: Notation
Reply-To: magnus.persson@xxxxxxxxxxxxxxxxx
Priority: normal
X-Sequence: 26
Precedence: list
>> <Magnus Persson>
> <David Fotland>
> >1) How do you make a program which never let a group be killed
> >unnecessarily (in the view of perhaps a one dan amateur) whatever
> >the state of the board. I.e a program that understand what a group
> >is and can evaluate its safety.
>
> An important extra condition is "without making very many
> unneccessary safety moves". It's easy to make a program
> that never leaves a weak group on the board. Just make lots
> of extra moves in close cases rather than reading. This approach
> leads to a very weak program of course, since it will waste lots
> of moves.
To me that is an obvious condition.
> Accurately evaluating group strength at dan level for non-enclosed,
> middlegame fighting groups, considering running moves, double
> attacks, etc. is extremely difficult.
That's why I only talk about computer go and almost never program
myself... :-)
> >2) How do you evaluate the state of all groups on the board without
> > making simple errors? Most (all?) programs of today cannot handle
> >situations where the fate of two weak groups overlap in tactical
> >fighting.
>
> I'd rather say that strong programs can handle many cases of
> overlapping groups in fights, but none can handle most cases. I
> think all programs will find double atari for example.
The point I want make is that a (truly) strong program must handle
*any* situation, not only those situations that are easily thought of
in beforehand of the programmer. When I used the term "tactical
fighting" I perhaps was not explicit enough. I tend to include
strategic fighting (eyeshape, running fights etc) into tactical
fighting or in other words: include are any kind of move that affects
the safety of stones that are not unconditionally live or dead. This
definition includes almost every move in a good game...
--
Magnus Persson
magnus.persson@xxxxxxxxxxxxxxxxx
http://www.docs.uu.se/~magnuspe
Department of psychology, Uppsala University
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Sender: pjl@xxxxxxxxxxxxxxxxx
Message-Id: <34F2B816.52BF@xxxxxxxxxxxxxxxxx>
Date: Tue, 24 Feb 1998 12:07:50 +0000
From: "P.J.Leonard" <P.J.Leonard@xxxxxxxxxxxxxxxxx>
Organization: Applied Electromagnetic Research Centre
X-Mailer: Mozilla 3.0 (X11; I; OSF1 V2.0 alpha)
Mime-Version: 1.0
To: computer-go@xxxxxxxxxxxxxxxxx
Subject: Re: Notation
References: <199802240849.JAA18252@xxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: computer-go@
X-Sequence: 27
Precedence: list
Magnus Persson wrote:
[snip]
> The point I want make is that a (truly) strong program must handle
> *any* situation, not only those situations that are easily thought of
> in beforehand of the programmer. When I used the term "tactical
> fighting" I perhaps was not explicit enough. I tend to include
> strategic fighting (eyeshape, running fights etc) into tactical
> fighting or in other words: include are any kind of move that affects
> the safety of stones that are not unconditionally live or dead. This
> definition includes almost every move in a good game...
Returning to the original theme of notation . . .
How do we (can we completely) classify (describe) all possible
situations ?
IMHO A notation for the descritpion of various goals (problems) in the
domain
of go would be of great use to the computer go community ?
Such a notation would need to supply some interesting definitions.
For example what is influence. I susspect we would all agree that
there is such a concept as influence but we would differ on its
definition.
Some things have clear definitions.
o Can a string live is clear cut providing we do not add auxillary
conditions.
o Can 2 strings connect is also clear.
Are there any other clear cut concepts ?
I would say that even if the definition of the concepts are unclear
a classification of concepts would be of use. For example what units
does one measure influence. Do we measure influence in terms of points
on the board that can be nominally connect to a living group of a
colour?
IMHO there are 3 reasons why a program might play badly.
1/ it is not using useful measures. (evaluation is incorrect)
2/ it is not finding moves that lead to a good measure. (move
suggestion bad)
3/ it is not exploring the search space effectively. (move ording and
search strategy is bad)
Given enough (probably infinite) resources we can eliminate 2 and 3.
IMHO a measure is most usefull if it can be applied at any point in the
game.
FOr example I would attempt to make the measures for influence and
territory
converge at the end of a game to the real score.
--
How do we measure thickness ? Is thickness a boolean quality that
states
that a set of strings can be connected ?
Do we have exact definitions for strategic concepts such as sente gote
moyo ?
cheers Paul.
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Message-Id: <01BD411A.D8B270D0@SOEGIH>
From: Soegi Hartono <Soegi_H@xxxxxxxxxxxxxxxxx>
To: "'computer-go@xxxxxxxxxxxxxxxxx'" <computer-go@xxxxxxxxxxxxxxxxx>
Subject: unsubscribe
Date: Tue, 24 Feb 1998 11:53:30 -0800
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: computer-go@
X-Sequence: 28
Precedence: list
unsubscribe
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Date: Wed, 25 Feb 1998 14:11:52 +0500 (PKT)
From: Muhammad Sayam Khan <b99079@xxxxxxxxxxxxxxxxx>
To: Soegi Hartono <Soegi_H@xxxxxxxxxxxxxxxxx>
Cc: "'computer-go@xxxxxxxxxxxxxxxxx'" <computer-go@xxxxxxxxxxxxxxxxx>
Subject: Re: unsubscribe
In-Reply-To: <01BD411A.D8B270D0@SOEGIH>
Message-Id: <Pine.BSF.3.95.980225141142.29269B-100000@xxxxxxxxxxxxxxxxx>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: computer-go@
X-Sequence: 29
Precedence: list
unsubscribe
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Sender: pjl@xxxxxxxxxxxxxxxxx
Message-Id: <34F40316.500F@xxxxxxxxxxxxxxxxx>
Date: Wed, 25 Feb 1998 11:40:06 +0000
From: "P.J.Leonard" <P.J.Leonard@xxxxxxxxxxxxxxxxx>
Organization: Applied Electromagnetic Research Centre
X-Mailer: Mozilla 3.0 (X11; I; OSF1 V2.0 alpha)
Mime-Version: 1.0
To: computer-go@xxxxxxxxxxxxxxxxx
Subject: Re:
References: <199802242251.XAA01120@xxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: computer-go@
X-Sequence: 30
Precedence: list
Hello,
This is a reply to a private mail that was also intended for the list
(we must tell the list owner to change the return to address).
Heikki Levanto wrote:
> On Tue, 24 Feb 1998 12:07:50 +0000 P.J.Leonard (P.J.Leonard@xxxxxxxxxxxxxxxxx)
> wrote in lsd.compgo:
>
> > IMHO there are 3 reasons why a program might play badly.
>
> > 1/ it is not using useful measures. (evaluation is incorrect)
>
> > 2/ it is not finding moves that lead to a good measure. (move
> > suggestion bad)
>
> > 3/ it is not exploring the search space effectively. (move ording and
> > search strategy is bad)
>
> I think you are assuming quite a lot of the structure of the program, namely
> that it consists of move suggestion, tree-like search, and leaf position
> evaluation. None of this has to be true... Consider, for example a program
> based on neural nets or other trained system.
Of course you are correct. I would however assert that any good program
would
have to do something analogous to these steps.
The disadvantage of neural nets is that they do not search (please give
me a reference
if I am wrong on this point). They are good at pattern recognition and
could be used
to suggest moves to put on a tree. I have doubts that a pure neural net
program
will ever become strong. Unless of course they evolve to the point of
performing
sequential logical reasoning.
The idea of a search tree to resolve the status of a goal is bound to
win (in the long term)
over a purely static analysis becuase it (in most cases) simplifies the
analysis
by making an unstable situation into a combination of more stable ones.
(not always
but sometimes).
> If I accept (for the sake of argument) your assumption, I guess I will have
> to agree that 2 and 3 can be solved with enough resources.
>
> Obviously 1 is the killer problem. I see it more as "Incorrect evaluation",
> for some reason. Useless measures are of course one source for bad
> evaluation, but I can think of others. Combining "simple" measures like life
> status or influence into a global value is far from trivial. Also, many
> terms people use for describing the situation are not at all simple to
> quantify, (how much less thick is a wall with one weakness? How important is
> one bad shape on the board?) Perhaps the measures can not be expressed in
> a (one-dimenstional) number at all? How do you measure the values of the
> opening move at the usual corner positions? Professionals use them all, so
> we can't just say one is better than other. Yet they have resons for their
> choices. How can we possibly quantify them??
Yes you have probably stated exactly what I was trying to say in my
post.
However, if we wish to progress we must try to quantify them. If we
want to compare programs we need common measures (notation).
> Although I find this sort of discussion interesting, and on some level
> useful, I can't help a strong feeling that it is missing the point. In my
> opinion the main problem is that the programs don't have much of an idea of
> what is going on in GO, hardly even what it is all about.
>
> Any comments?
I think we share the same feeling about the problems.
Professionals use complex measures that they can not verbally explain.
So how can we expect a go program to mimic the undefinable behaviour.
1. Do you think that we should attempt to understand how good go players
think ?
(I think so)
2. Do you think that this (1) is the best way to proceed in computer GO.
If not what should
be our focus.
3. Assuming you agree that an analysis of how we solve problems is worth
while. Surely
the first step is to classify the problems ?
4. The classification of problems requires a language to describe the
goal.
5. The first problem is to describe these goals.
Without this excercise you do not know what problem you are trying to
solve.
Is it possible to solve problems without understanding what you are
trying to do ?
A go program that makes moves simply base on good shape rules might beat
a program
that simply attacks the oponents weakest group.
Both programs have goals (Make good shape) (Attack weak group).
I think we would agree move suggesters for these goals are losely
connected
to the ultimate aim of gaining the most territory. But not directly.
Such programs
ultimate fall down because they do not form strategic plans that aim at
long term
goals.
Here is my bottom line.
1. I think the evaluation of influence/territory can be done to an
adequit accuracy
IF (a very big if) you are given the alive/dead status of all the
strings (your program
must be smart enough to work out that status). Unsettled strings still
bother me at the moment
because these involve a combinational type reasoning.
2. They alive/dead status of a string (independent of other things) is
possible but requires
fairly good move suggesters and search strategy.
3. Using the technology of (1) it should be possible to identify
important strings (flaging them
dead will change the influence measure). It should also be possible to
use (1) to estimate the value
of planting new strings on the board.
4. The big IF is the accuate estimate of the status of the strings (with
the interactions).
This requires some pretty
smart searching. In fact you must first decide if it is worth saving a
given string (you do not want to waste
effort proving useless information).
This can be directed by the estimate of value given by (3). For example
the global search
could be seed by string of the most worth. As more strings are planted
the interaction
of sub searches should trigger the planting of composite goals (not
easy). I believe (but
I am open to other ideas) that the search should be directed by pure
goals (not values yet).
The end points of the search are candidates for reevaluation (1) with
less instability.
5. The big problem is the overlapping of the searchs. It is possible to
localize a search
by restricting its context to a single string (or a cluster of
strings). However the results
of 2 local searchs can not be taken as independent. If the area of the
searches do not
overlap it may be possible to treat them as independent but a large
number of cases will
involve logic that involves
a) who moves first in a local situation,
b) does the sequence end in sente or gote.
c) does the end of the search invalidate the results of other searches
because of overlap.
Non overlapping searches have the advantage that they can be analysised
independently and the
results combined in a combinational fashion.
6. A proper analysis of (5) is just a horrific nightmare. However I
imagine a search strategy
that explores local goals, forms composite goals when areas overlap
(e.g. the goal could
be see if string A and B can collaborate to live). I expect that this
search will be resource
limited.
7. Once I have run out of resources I have got a tree full of sequences.
I am hoping
that it is possible to generate a tree which contains the look ahead
that a good
go player would do. This tree is a result of focused analysis.
8. I can apply (1) to the end of these sequences and try to find the
move that garantees the best score.
9. We could get recursive here.
Sorry about the length of the post.
cheers Paul.
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Date: Wed, 25 Feb 1998 13:55:41 +0100 (MET)
From: Jan Ramon <Jan.Ramon@xxxxxxxxxxxxxxxxx>
Reply-To: Jan Ramon <Jan.Ramon@xxxxxxxxxxxxxxxxx>
To: "P.J.Leonard" <P.J.Leonard@xxxxxxxxxxxxxxxxx>
Cc: computer-go@xxxxxxxxxxxxxxxxx
Subject: Re: Notation
In-Reply-To: <34F2B816.52BF@xxxxxxxxxxxxxxxxx>
Message-Id:
<Pine.GSO.3.95.980224141247.14876L-100000@xxxxxxxxxxxxxxxxx>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Sequence: 31
Precedence: list
On Tue, 24 Feb 1998, P.J.Leonard wrote:
> How do we (can we completely) classify (describe) all possible
> situations ?
>
> IMHO A notation for the descritpion of various goals (problems) in the
> domain of go would be of great use to the computer go community ?
i agree with this
> Such a notation would need to supply some interesting definitions.
> For example what is influence. I susspect we would all agree that
> there is such a concept as influence but we would differ on its
> definition.
>
> Some things have clear definitions.
> o Can a string live is clear cut providing we do not add auxillary
> conditions.
> o Can 2 strings connect is also clear.
>
> Are there any other clear cut concepts ?
i think, if 'can string live' and 'can strings connect' are clear-cut
concepts, we can define recursively all other 'functional' concepts such
as 'can these two strings live' and 'can at least one of these strings
live'.
>
> I would say that even if the definition of the concepts are unclear
> a classification of concepts would be of use.
imho, we have two main classes:
- functional concepts that can be verified (proved) by searching the
move-tree (can string live? can strings connect? ...)
- heuristic concepts that we humans can feel but don't understand (we dont
have a clear definition) such as 'influence' 'good shape' ...
> For example what units
> does one measure influence. Do we measure influence in terms of points
> on the board that can be nominally connect to a living group of a
> colour?
i'm not a strong player, but i thought the value of influence depends also
on the other positions on the board (e.g. sometimes a few stones can
'neutralise' thickness). moreover there is a difference between influence
(e.g. wall) and thickness i thought. however, the number of points that
can connect to these structures can be the same.
> IMHO there are 3 reasons why a program might play badly.
> 1/ it is not using useful measures. (evaluation is incorrect)
> 2/ it is not finding moves that lead to a good measure. (move
> suggestion bad)
> 3/ it is not exploring the search space effectively. (move ording and
> search strategy is bad)
i would like to add
4/ the thinking in search trees, move suggestions and evaluation is bad.
>
> Given enough (probably infinite) resources we can eliminate 2 and 3.
i don't think this helps us. if we had infinite resources, we could
simply search the full game tree which is definitely bounded by 3**361
nodes :-)
> How do we measure thickness ? Is thickness a boolean quality that
> states that a set of strings can be connected ?
>
> Do we have exact definitions for strategic concepts such as sente gote
> moyo ?
sente and gote must be possible to define exact if we can define
'locality' exact (with locality i mean when is a move tenuki (play
elsewhere, so sente) and when is it not (gote?).
So i would define 'locality' (and from this also sente and gote) with
respect to some 'exactly' defined *goal*. (e.g. "this move Xis tenuki with
respect to life/death of group X because i can prove that it doesn't
affect the life/death status of that group (if i passed, the status of
that group would be the same)).
Also in real play 'absolute sente' doesn't exist (you can always tenuki
even if you lose a group with that). So "move M is sente with respect to
connection C" means that
- if the opponent tenukis, the connection status of C has changed.
- if the opponent doesn't tenuki, the connection status of C
remains as it was before move M
moyo is a heuristic concept and can not be defined exactly i think
jan
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Message-Id: <34F42C0A.50C5@xxxxxxxxxxxxxxxxx>
Date: Wed, 25 Feb 1998 15:34:50 +0100
From: Robert Jasiek <jasiek@xxxxxxxxxxxxxxxxx>
Reply-To: jasiek@xxxxxxxxxxxxxxxxx
X-Mailer: Mozilla 3.01Gold (Win95; I)
Mime-Version: 1.0
To: Jan Ramon <Jan.Ramon@xxxxxxxxxxxxxxxxx>
Cc: ML computer go <computer-go@xxxxxxxxxxxxxxxxx>
Subject: Re: Notation
References: <md5:01D91AF37D2A4F762D9D1DB002DC45A9>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sequence: 32
Precedence: list
> the full game tree which is definitely bounded by 3**361 nodes :-)
Sorry, but I thought 361**3**361. How do you proof 3**361 ? I can
prove 3**361 to be [about] the upper depth of a simple rules tree.
You give a branching factor of 1 for each node, but it should be
361 :(
--
robert jasiek
NEW: http://www.snafu.de/~jasiek/rules.html
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Date: Wed, 25 Feb 1998 15:47:42 +0100 (MET)
From: Jan Ramon <Jan.Ramon@xxxxxxxxxxxxxxxxx>
To: Robert Jasiek <jasiek@xxxxxxxxxxxxxxxxx>
Cc: ML computer go <computer-go@xxxxxxxxxxxxxxxxx>
Subject: Re: Notation
In-Reply-To: <34F42C0A.50C5@xxxxxxxxxxxxxxxxx>
Message-Id:
<Pine.GSO.3.95.980225154219.14876V-100000@xxxxxxxxxxxxxxxxx>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: computer-go@
X-Sequence: 33
Precedence: list
On Wed, 25 Feb 1998, Robert Jasiek wrote:
> > the full game tree which is definitely bounded by 3**361 nodes :-)
>
> Sorry, but I thought 361**3**361. How do you proof 3**361 ? I can
> prove 3**361 to be [about] the upper depth of a simple rules tree.
> You give a branching factor of 1 for each node, but it should be
> 361 :(
it was not my intention to start to 'upper bound discussion' from some
time ago again. i simply wrote 'upper bound 3**361' because this is the
maximal number of positions (in fact some positions are illegal e.g.
groups without liberties). using transposition tables etc. we have a
search tree (more exactly a finite state automaton) with at most 3**361
nodes and in each node at most 361 other nodes reachable from that nodes.
some nodes are marked 'win', some other 'lose'.
jan
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
From: "Jill Irving" <jirving@xxxxxxxxxxxxxxxxx>
Message-Id: <980227150825.ZM21322@xxxxxxxxxxxxxxxxx>
Date: Fri, 27 Feb 1998 15:08:24 -0500
In-Reply-To: "P.J.Leonard" <P.J.Leonard@xxxxxxxxxxxxxxxxx> "Re: Notation" (Feb 24,
12:07pm)
References: <199802240849.JAA18252@xxxxxxxxxxxxxxxxx> <34F2B816.52BF@xxxxxxxxxxxxxxxxx>
X-Mailer: Z-Mail (4.0.1 13Jan97)
To: "P.J.Leonard" <P.J.Leonard@xxxxxxxxxxxxxxxxx>
Subject: Re: Notation
Cc: computer-go@xxxxxxxxxxxxxxxxx
Mime-Version: 1.0
Content-Type: multipart/mixed;
boundary="PART-BOUNDARY=.1980227150824.ZM21322.ucc.su.OZ.AU"
Reply-To: computer-go@
X-Sequence: 34
Precedence: list
--
--PART-BOUNDARY=.1980227150824.ZM21322.ucc.su.OZ.AU
Content-Type: text/plain; charset=us-ascii
hello
I'm wondering how, with only one advantage point, I captured so many white
stones. Is it possible to play this game on 19x19 with better scoring?
--PART-BOUNDARY=.1980227150824.ZM21322.ucc.su.OZ.AU
Content-Description: Data
Content-Type: application/octet-stream ; name="v4BC-JqqQM8YqGgGWinHoHqgUEQqWgmCA"
Content-Transfer-Encoding: base64
Content-Disposition: attachment ; filename="v4BC-JqqQM8YqGgGWinHoHqgUEQqWgmCA"
X-Zm-Content-Name: v4BC-JqqQM8YqGgGWinHoHqgUEQqWgmCA
X-Zm-Decoding-Hint: mimencode -b -u
PEhUTUw+CjxIRUFEPjxUSVRMRT5BIGdhbWUgd2l0aCBKb2dvPC9USVRMRT48L0hFQUQ+CjxC
T0RZPgo8UD4KVGhlIGdhbWUgaXMgb3Zlci4KPEJSPgpTdG9uZXMgY2FwdHVyZWQgYnkgQmxh
Y2s6IDEsIGJ5IFdoaXRlOiAyMgo8UD4KPEEgSFJFRj0idjRCQy1KcXFRTThZcUdnR1dpbkhv
SHFnVUVRcVdnbUMxP29vIj48SU1HIFNSQz0iaHR0cDovL3d3dy5qb2VyY2gub3JnL2dvLzEu
Z2lmIiBCT1JERVI9IjAiQUxUPSIuIj48L0EKPjxBIEhSRUY9InY0QkMtSnFxUU04WXFHZ0dX
aW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9Imh0dHA6Ly93d3cuam9lcmNoLm9yZy9n
by8yLmdpZiIgQk9SREVSPSIwIkFMVD0iLiI+PC9BCj48QSBIUkVGPSJ2NEJDLUpxcVFNOFlx
R2dHV2luSG9IcWdVRVFxV2dtQzE/b28iPjxJTUcgU1JDPSJodHRwOi8vd3d3LmpvZXJjaC5v
cmcvZ28vYi5naWYiIEJPUkRFUj0iMCJBTFQ9IngiPjwvQQo+PEEgSFJFRj0idjRCQy1KcXFR
TThZcUdnR1dpbkhvSHFnVUVRcVdnbUMxP29vIj48SU1HIFNSQz0iaHR0cDovL3d3dy5qb2Vy
Y2gub3JnL2dvL3cuZ2lmIiBCT1JERVI9IjAiQUxUPSJvIj48L0EKPjxBIEhSRUY9InY0QkMt
SnFxUU04WXFHZ0dXaW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9Imh0dHA6Ly93d3cu
am9lcmNoLm9yZy9nby93LmdpZiIgQk9SREVSPSIwIkFMVD0ibyI+PC9BCj48QSBIUkVGPSJ2
NEJDLUpxcVFNOFlxR2dHV2luSG9IcWdVRVFxV2dtQzE/b28iPjxJTUcgU1JDPSJodHRwOi8v
d3d3LmpvZXJjaC5vcmcvZ28vdy5naWYiIEJPUkRFUj0iMCJBTFQ9Im8iPjwvQQo+PEEgSFJF
Rj0idjRCQy1KcXFRTThZcUdnR1dpbkhvSHFnVUVRcVdnbUMxP29vIj48SU1HIFNSQz0iaHR0
cDovL3d3dy5qb2VyY2gub3JnL2dvL3cuZ2lmIiBCT1JERVI9IjAiQUxUPSJvIj48L0EKPjxB
IEhSRUY9InY0QkMtSnFxUU04WXFHZ0dXaW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9
Imh0dHA6Ly93d3cuam9lcmNoLm9yZy9nby93LmdpZiIgQk9SREVSPSIwIkFMVD0ibyI+PC9B
Cj48QSBIUkVGPSJ2NEJDLUpxcVFNOFlxR2dHV2luSG9IcWdVRVFxV2dtQzE/b28iPjxJTUcg
U1JDPSJodHRwOi8vd3d3LmpvZXJjaC5vcmcvZ28vdy5naWYiIEJPUkRFUj0iMCJBTFQ9Im8i
PjwvQQo+PEJSPjxBIEhSRUY9InY0QkMtSnFxUU04WXFHZ0dXaW5Ib0hxZ1VFUXFXZ21DMT9v
byI+PElNRyBTUkM9Imh0dHA6Ly93d3cuam9lcmNoLm9yZy9nby9iLmdpZiIgQk9SREVSPSIw
IkFMVD0ieCI+PC9BCj48QSBIUkVGPSJ2NEJDLUpxcVFNOFlxR2dHV2luSG9IcWdVRVFxV2dt
QzE/b28iPjxJTUcgU1JDPSJodHRwOi8vd3d3LmpvZXJjaC5vcmcvZ28vYi5naWYiIEJPUkRF
Uj0iMCJBTFQ9IngiPjwvQQo+PEEgSFJFRj0idjRCQy1KcXFRTThZcUdnR1dpbkhvSHFnVUVR
cVdnbUMxP29vIj48SU1HIFNSQz0iaHR0cDovL3d3dy5qb2VyY2gub3JnL2dvL2IuZ2lmIiBC
T1JERVI9IjAiQUxUPSJ4Ij48L0EKPjxBIEhSRUY9InY0QkMtSnFxUU04WXFHZ0dXaW5Ib0hx
Z1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9Imh0dHA6Ly93d3cuam9lcmNoLm9yZy9nby93Lmdp
ZiIgQk9SREVSPSIwIkFMVD0ibyI+PC9BCj48QSBIUkVGPSJ2NEJDLUpxcVFNOFlxR2dHV2lu
SG9IcWdVRVFxV2dtQzE/b28iPjxJTUcgU1JDPSJodHRwOi8vd3d3LmpvZXJjaC5vcmcvZ28v
MC5naWYiIEJPUkRFUj0iMCJBTFQ9Ii4iPjwvQQo+PEEgSFJFRj0idjRCQy1KcXFRTThZcUdn
R1dpbkhvSHFnVUVRcVdnbUMxP29vIj48SU1HIFNSQz0iaHR0cDovL3d3dy5qb2VyY2gub3Jn
L2dvL2IuZ2lmIiBCT1JERVI9IjAiQUxUPSJ4Ij48L0EKPjxBIEhSRUY9InY0QkMtSnFxUU04
WXFHZ0dXaW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9Imh0dHA6Ly93d3cuam9lcmNo
Lm9yZy9nby9iLmdpZiIgQk9SREVSPSIwIkFMVD0ieCI+PC9BCj48QSBIUkVGPSJ2NEJDLUpx
cVFNOFlxR2dHV2luSG9IcWdVRVFxV2dtQzE/b28iPjxJTUcgU1JDPSJodHRwOi8vd3d3Lmpv
ZXJjaC5vcmcvZ28vYi5naWYiIEJPUkRFUj0iMCJBTFQ9IngiPjwvQQo+PEEgSFJFRj0idjRC
Qy1KcXFRTThZcUdnR1dpbkhvSHFnVUVRcVdnbUMxP29vIj48SU1HIFNSQz0iaHR0cDovL3d3
dy5qb2VyY2gub3JnL2dvLzQuZ2lmIiBCT1JERVI9IjAiQUxUPSIuIj48L0EKPjxCUj48QSBI
UkVGPSJ2NEJDLUpxcVFNOFlxR2dHV2luSG9IcWdVRVFxV2dtQzE/b28iPjxJTUcgU1JDPSJo
dHRwOi8vd3d3LmpvZXJjaC5vcmcvZ28vdy5naWYiIEJPUkRFUj0iMCJBTFQ9Im8iPjwvQQo+
PEEgSFJFRj0idjRCQy1KcXFRTThZcUdnR1dpbkhvSHFnVUVRcVdnbUMxP29vIj48SU1HIFNS
Qz0iaHR0cDovL3d3dy5qb2VyY2gub3JnL2dvL3cuZ2lmIiBCT1JERVI9IjAiQUxUPSJvIj48
L0EKPjxBIEhSRUY9InY0QkMtSnFxUU04WXFHZ0dXaW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElN
RyBTUkM9Imh0dHA6Ly93d3cuam9lcmNoLm9yZy9nby9iLmdpZiIgQk9SREVSPSIwIkFMVD0i
eCI+PC9BCj48QSBIUkVGPSJ2NEJDLUpxcVFNOFlxR2dHV2luSG9IcWdVRVFxV2dtQzE/b28i
PjxJTUcgU1JDPSJodHRwOi8vd3d3LmpvZXJjaC5vcmcvZ28vdy5naWYiIEJPUkRFUj0iMCJB
TFQ9Im8iPjwvQQo+PEEgSFJFRj0idjRCQy1KcXFRTThZcUdnR1dpbkhvSHFnVUVRcVdnbUMx
P29vIj48SU1HIFNSQz0iaHR0cDovL3d3dy5qb2VyY2gub3JnL2dvL3cuZ2lmIiBCT1JERVI9
IjAiQUxUPSJvIj48L0EKPjxBIEhSRUY9InY0QkMtSnFxUU04WXFHZ0dXaW5Ib0hxZ1VFUXFX
Z21DMT9vbyI+PElNRyBTUkM9Imh0dHA6Ly93d3cuam9lcmNoLm9yZy9nby93LmdpZiIgQk9S
REVSPSIwIkFMVD0ibyI+PC9BCj48QSBIUkVGPSJ2NEJDLUpxcVFNOFlxR2dHV2luSG9IcWdV
RVFxV2dtQzE/b28iPjxJTUcgU1JDPSJodHRwOi8vd3d3LmpvZXJjaC5vcmcvZ28vdy5naWYi
IEJPUkRFUj0iMCJBTFQ9Im8iPjwvQQo+PEEgSFJFRj0idjRCQy1KcXFRTThZcUdnR1dpbkhv
SHFnVUVRcVdnbUMxP29vIj48SU1HIFNSQz0iaHR0cDovL3d3dy5qb2VyY2gub3JnL2dvL3cu
Z2lmIiBCT1JERVI9IjAiQUxUPSJvIj48L0EKPjxBIEhSRUY9InY0QkMtSnFxUU04WXFHZ0dX
aW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9Imh0dHA6Ly93d3cuam9lcmNoLm9yZy9n
by80LmdpZiIgQk9SREVSPSIwIkFMVD0iLiI+PC9BCj48QlI+PEEgSFJFRj0idjRCQy1KcXFR
TThZcUdnR1dpbkhvSHFnVUVRcVdnbUMxP29vIj48SU1HIFNSQz0iaHR0cDovL3d3dy5qb2Vy
Y2gub3JnL2dvLzguZ2lmIiBCT1JERVI9IjAiQUxUPSIuIj48L0EKPjxBIEhSRUY9InY0QkMt
SnFxUU04WXFHZ0dXaW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9Imh0dHA6Ly93d3cu
am9lcmNoLm9yZy9nby9iLmdpZiIgQk9SREVSPSIwIkFMVD0ieCI+PC9BCj48QSBIUkVGPSJ2
NEJDLUpxcVFNOFlxR2dHV2luSG9IcWdVRVFxV2dtQzE/b28iPjxJTUcgU1JDPSJodHRwOi8v
d3d3LmpvZXJjaC5vcmcvZ28vdy5naWYiIEJPUkRFUj0iMCJBTFQ9Im8iPjwvQQo+PEEgSFJF
Rj0idjRCQy1KcXFRTThZcUdnR1dpbkhvSHFnVUVRcVdnbUMxP29vIj48SU1HIFNSQz0iaHR0
cDovL3d3dy5qb2VyY2gub3JnL2dvL3cuZ2lmIiBCT1JERVI9IjAiQUxUPSJvIj48L0EKPjxB
IEhSRUY9InY0QkMtSnFxUU04WXFHZ0dXaW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9
Imh0dHA6Ly93d3cuam9lcmNoLm9yZy9nby93LmdpZiIgQk9SREVSPSIwIkFMVD0ibyI+PC9B
Cj48QSBIUkVGPSJ2NEJDLUpxcVFNOFlxR2dHV2luSG9IcWdVRVFxV2dtQzE/b28iPjxJTUcg
U1JDPSJodHRwOi8vd3d3LmpvZXJjaC5vcmcvZ28vMC5naWYiIEJPUkRFUj0iMCJBTFQ9Ii4i
PjwvQQo+PEEgSFJFRj0idjRCQy1KcXFRTThZcUdnR1dpbkhvSHFnVUVRcVdnbUMxP29vIj48
SU1HIFNSQz0iaHR0cDovL3d3dy5qb2VyY2gub3JnL2dvL2IuZ2lmIiBCT1JERVI9IjAiQUxU
PSJ4Ij48L0EKPjxBIEhSRUY9InY0QkMtSnFxUU04WXFHZ0dXaW5Ib0hxZ1VFUXFXZ21DMT9v
byI+PElNRyBTUkM9Imh0dHA6Ly93d3cuam9lcmNoLm9yZy9nby93LmdpZiIgQk9SREVSPSIw
IkFMVD0ibyI+PC9BCj48QSBIUkVGPSJ2NEJDLUpxcVFNOFlxR2dHV2luSG9IcWdVRVFxV2dt
QzE/b28iPjxJTUcgU1JDPSJodHRwOi8vd3d3LmpvZXJjaC5vcmcvZ28vYi5naWYiIEJPUkRF
Uj0iMCJBTFQ9IngiPjwvQQo+PEJSPjxBIEhSRUY9InY0QkMtSnFxUU04WXFHZ0dXaW5Ib0hx
Z1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9Imh0dHA6Ly93d3cuam9lcmNoLm9yZy9nby9iLmdp
ZiIgQk9SREVSPSIwIkFMVD0ieCI+PC9BCj48QSBIUkVGPSJ2NEJDLUpxcVFNOFlxR2dHV2lu
SG9IcWdVRVFxV2dtQzE/b28iPjxJTUcgU1JDPSJodHRwOi8vd3d3LmpvZXJjaC5vcmcvZ28v
Yi5naWYiIEJPUkRFUj0iMCJBTFQ9IngiPjwvQQo+PEEgSFJFRj0idjRCQy1KcXFRTThZcUdn
R1dpbkhvSHFnVUVRcVdnbUMxP29vIj48SU1HIFNSQz0iaHR0cDovL3d3dy5qb2VyY2gub3Jn
L2dvL3cuZ2lmIiBCT1JERVI9IjAiQUxUPSJvIj48L0EKPjxBIEhSRUY9InY0QkMtSnFxUU04
WXFHZ0dXaW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9Imh0dHA6Ly93d3cuam9lcmNo
Lm9yZy9nby8wLmdpZiIgQk9SREVSPSIwIkFMVD0iLiI+PC9BCj48QSBIUkVGPSJ2NEJDLUpx
cVFNOFlxR2dHV2luSG9IcWdVRVFxV2dtQzE/b28iPjxJTUcgU1JDPSJodHRwOi8vd3d3Lmpv
ZXJjaC5vcmcvZ28vdy5naWYiIEJPUkRFUj0iMCJBTFQ9Im8iPjwvQQo+PEEgSFJFRj0idjRC
Qy1KcXFRTThZcUdnR1dpbkhvSHFnVUVRcVdnbUMxP29vIj48SU1HIFNSQz0iaHR0cDovL3d3
dy5qb2VyY2gub3JnL2dvL3cuZ2lmIiBCT1JERVI9IjAiQUxUPSJvIj48L0EKPjxBIEhSRUY9
InY0QkMtSnFxUU04WXFHZ0dXaW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9Imh0dHA6
Ly93d3cuam9lcmNoLm9yZy9nby93LmdpZiIgQk9SREVSPSIwIkFMVD0ibyI+PC9BCj48QSBI
UkVGPSJ2NEJDLUpxcVFNOFlxR2dHV2luSG9IcWdVRVFxV2dtQzE/b28iPjxJTUcgU1JDPSJo
dHRwOi8vd3d3LmpvZXJjaC5vcmcvZ28vdy5naWYiIEJPUkRFUj0iMCJBTFQ9Im8iPjwvQQo+
PEEgSFJFRj0idjRCQy1KcXFRTThZcUdnR1dpbkhvSHFnVUVRcVdnbUMxP29vIj48SU1HIFNS
Qz0iaHR0cDovL3d3dy5qb2VyY2gub3JnL2dvLzQuZ2lmIiBCT1JERVI9IjAiQUxUPSIuIj48
L0EKPjxCUj48QSBIUkVGPSJ2NEJDLUpxcVFNOFlxR2dHV2luSG9IcWdVRVFxV2dtQzE/b28i
PjxJTUcgU1JDPSJodHRwOi8vd3d3LmpvZXJjaC5vcmcvZ28vYi5naWYiIEJPUkRFUj0iMCJB
TFQ9IngiPjwvQQo+PEEgSFJFRj0idjRCQy1KcXFRTThZcUdnR1dpbkhvSHFnVUVRcVdnbUMx
P29vIj48SU1HIFNSQz0iaHR0cDovL3d3dy5qb2VyY2gub3JnL2dvL3cuZ2lmIiBCT1JERVI9
IjAiQUxUPSJvIj48L0EKPjxBIEhSRUY9InY0QkMtSnFxUU04WXFHZ0dXaW5Ib0hxZ1VFUXFX
Z21DMT9vbyI+PElNRyBTUkM9Imh0dHA6Ly93d3cuam9lcmNoLm9yZy9nby93LmdpZiIgQk9S
REVSPSIwIkFMVD0ibyI+PC9BCj48QSBIUkVGPSJ2NEJDLUpxcVFNOFlxR2dHV2luSG9IcWdV
RVFxV2dtQzE/b28iPjxJTUcgU1JDPSJodHRwOi8vd3d3LmpvZXJjaC5vcmcvZ28vdy5naWYi
IEJPUkRFUj0iMCJBTFQ9Im8iPjwvQQo+PEEgSFJFRj0idjRCQy1KcXFRTThZcUdnR1dpbkhv
SHFnVUVRcVdnbUMxP29vIj48SU1HIFNSQz0iaHR0cDovL3d3dy5qb2VyY2gub3JnL2dvL3cu
Z2lmIiBCT1JERVI9IjAiQUxUPSJvIj48L0EKPjxBIEhSRUY9InY0QkMtSnFxUU04WXFHZ0dX
aW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9Imh0dHA6Ly93d3cuam9lcmNoLm9yZy9n
by8wLmdpZiIgQk9SREVSPSIwIkFMVD0iLiI+PC9BCj48QSBIUkVGPSJ2NEJDLUpxcVFNOFlx
R2dHV2luSG9IcWdVRVFxV2dtQzE/b28iPjxJTUcgU1JDPSJodHRwOi8vd3d3LmpvZXJjaC5v
cmcvZ28vdy5naWYiIEJPUkRFUj0iMCJBTFQ9Im8iPjwvQQo+PEEgSFJFRj0idjRCQy1KcXFR
TThZcUdnR1dpbkhvSHFnVUVRcVdnbUMxP29vIj48SU1HIFNSQz0iaHR0cDovL3d3dy5qb2Vy
Y2gub3JnL2dvL3cuZ2lmIiBCT1JERVI9IjAiQUxUPSJvIj48L0EKPjxBIEhSRUY9InY0QkMt
SnFxUU04WXFHZ0dXaW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9Imh0dHA6Ly93d3cu
am9lcmNoLm9yZy9nby93LmdpZiIgQk9SREVSPSIwIkFMVD0ibyI+PC9BCj48QlI+PEEgSFJF
Rj0idjRCQy1KcXFRTThZcUdnR1dpbkhvSHFnVUVRcVdnbUMxP29vIj48SU1HIFNSQz0iaHR0
cDovL3d3dy5qb2VyY2gub3JnL2dvLzguZ2lmIiBCT1JERVI9IjAiQUxUPSIuIj48L0EKPjxB
IEhSRUY9InY0QkMtSnFxUU04WXFHZ0dXaW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9
Imh0dHA6Ly93d3cuam9lcmNoLm9yZy9nby9iLmdpZiIgQk9SREVSPSIwIkFMVD0ieCI+PC9B
Cj48QSBIUkVGPSJ2NEJDLUpxcVFNOFlxR2dHV2luSG9IcWdVRVFxV2dtQzE/b28iPjxJTUcg
U1JDPSJodHRwOi8vd3d3LmpvZXJjaC5vcmcvZ28vdy5naWYiIEJPUkRFUj0iMCJBTFQ9Im8i
PjwvQQo+PEEgSFJFRj0idjRCQy1KcXFRTThZcUdnR1dpbkhvSHFnVUVRcVdnbUMxP29vIj48
SU1HIFNSQz0iaHR0cDovL3d3dy5qb2VyY2gub3JnL2dvLzAuZ2lmIiBCT1JERVI9IjAiQUxU
PSIuIj48L0EKPjxBIEhSRUY9InY0QkMtSnFxUU04WXFHZ0dXaW5Ib0hxZ1VFUXFXZ21DMT9v
byI+PElNRyBTUkM9Imh0dHA6Ly93d3cuam9lcmNoLm9yZy9nby93LmdpZiIgQk9SREVSPSIw
IkFMVD0ibyI+PC9BCj48QSBIUkVGPSJ2NEJDLUpxcVFNOFlxR2dHV2luSG9IcWdVRVFxV2dt
QzE/b28iPjxJTUcgU1JDPSJodHRwOi8vd3d3LmpvZXJjaC5vcmcvZ28vYi5naWYiIEJPUkRF
Uj0iMCJBTFQ9IngiPjwvQQo+PEEgSFJFRj0idjRCQy1KcXFRTThZcUdnR1dpbkhvSHFnVUVR
cVdnbUMxP29vIj48SU1HIFNSQz0iaHR0cDovL3d3dy5qb2VyY2gub3JnL2dvL2IuZ2lmIiBC
T1JERVI9IjAiQUxUPSJ4Ij48L0EKPjxBIEhSRUY9InY0QkMtSnFxUU04WXFHZ0dXaW5Ib0hx
Z1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9Imh0dHA6Ly93d3cuam9lcmNoLm9yZy9nby93Lmdp
ZiIgQk9SREVSPSIwIkFMVD0ibyI+PC9BCj48QSBIUkVGPSJ2NEJDLUpxcVFNOFlxR2dHV2lu
SG9IcWdVRVFxV2dtQzE/b28iPjxJTUcgU1JDPSJodHRwOi8vd3d3LmpvZXJjaC5vcmcvZ28v
NC5naWYiIEJPUkRFUj0iMCJBTFQ9Ii4iPjwvQQo+PEJSPjxBIEhSRUY9InY0QkMtSnFxUU04
WXFHZ0dXaW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9Imh0dHA6Ly93d3cuam9lcmNo
Lm9yZy9nby9iLmdpZiIgQk9SREVSPSIwIkFMVD0ieCI+PC9BCj48QSBIUkVGPSJ2NEJDLUpx
cVFNOFlxR2dHV2luSG9IcWdVRVFxV2dtQzE/b28iPjxJTUcgU1JDPSJodHRwOi8vd3d3Lmpv
ZXJjaC5vcmcvZ28vYi5naWYiIEJPUkRFUj0iMCJBTFQ9IngiPjwvQQo+PEEgSFJFRj0idjRC
Qy1KcXFRTThZcUdnR1dpbkhvSHFnVUVRcVdnbUMxP29vIj48SU1HIFNSQz0iaHR0cDovL3d3
dy5qb2VyY2gub3JnL2dvL2IuZ2lmIiBCT1JERVI9IjAiQUxUPSJ4Ij48L0EKPjxBIEhSRUY9
InY0QkMtSnFxUU04WXFHZ0dXaW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9Imh0dHA6
Ly93d3cuam9lcmNoLm9yZy9nby93LmdpZiIgQk9SREVSPSIwIkFMVD0ibyI+PC9BCj48QSBI
UkVGPSJ2NEJDLUpxcVFNOFlxR2dHV2luSG9IcWdVRVFxV2dtQzE/b28iPjxJTUcgU1JDPSJo
dHRwOi8vd3d3LmpvZXJjaC5vcmcvZ28vdy5naWYiIEJPUkRFUj0iMCJBTFQ9Im8iPjwvQQo+
PEEgSFJFRj0idjRCQy1KcXFRTThZcUdnR1dpbkhvSHFnVUVRcVdnbUMxP29vIj48SU1HIFNS
Qz0iaHR0cDovL3d3dy5qb2VyY2gub3JnL2dvL3cuZ2lmIiBCT1JERVI9IjAiQUxUPSJvIj48
L0EKPjxBIEhSRUY9InY0QkMtSnFxUU04WXFHZ0dXaW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElN
RyBTUkM9Imh0dHA6Ly93d3cuam9lcmNoLm9yZy9nby9iLmdpZiIgQk9SREVSPSIwIkFMVD0i
eCI+PC9BCj48QSBIUkVGPSJ2NEJDLUpxcVFNOFlxR2dHV2luSG9IcWdVRVFxV2dtQzE/b28i
PjxJTUcgU1JDPSJodHRwOi8vd3d3LmpvZXJjaC5vcmcvZ28vdy5naWYiIEJPUkRFUj0iMCJB
TFQ9Im8iPjwvQQo+PEEgSFJFRj0idjRCQy1KcXFRTThZcUdnR1dpbkhvSHFnVUVRcVdnbUMx
P29vIj48SU1HIFNSQz0iaHR0cDovL3d3dy5qb2VyY2gub3JnL2dvL2IuZ2lmIiBCT1JERVI9
IjAiQUxUPSJ4Ij48L0EKPjxCUj48QSBIUkVGPSJ2NEJDLUpxcVFNOFlxR2dHV2luSG9IcWdV
RVFxV2dtQzE/b28iPjxJTUcgU1JDPSJodHRwOi8vd3d3LmpvZXJjaC5vcmcvZ28vNy5naWYi
IEJPUkRFUj0iMCJBTFQ9Ii4iPjwvQQo+PEEgSFJFRj0idjRCQy1KcXFRTThZcUdnR1dpbkhv
SHFnVUVRcVdnbUMxP29vIj48SU1HIFNSQz0iaHR0cDovL3d3dy5qb2VyY2gub3JnL2dvL2Iu
Z2lmIiBCT1JERVI9IjAiQUxUPSJ4Ij48L0EKPjxBIEhSRUY9InY0QkMtSnFxUU04WXFHZ0dX
aW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9Imh0dHA6Ly93d3cuam9lcmNoLm9yZy9n
by93LmdpZiIgQk9SREVSPSIwIkFMVD0ibyI+PC9BCj48QSBIUkVGPSJ2NEJDLUpxcVFNOFlx
R2dHV2luSG9IcWdVRVFxV2dtQzE/b28iPjxJTUcgU1JDPSJodHRwOi8vd3d3LmpvZXJjaC5v
cmcvZ28vNi5naWYiIEJPUkRFUj0iMCJBTFQ9Ii4iPjwvQQo+PEEgSFJFRj0idjRCQy1KcXFR
TThZcUdnR1dpbkhvSHFnVUVRcVdnbUMxP29vIj48SU1HIFNSQz0iaHR0cDovL3d3dy5qb2Vy
Y2gub3JnL2dvL3cuZ2lmIiBCT1JERVI9IjAiQUxUPSJvIj48L0EKPjxBIEhSRUY9InY0QkMt
SnFxUU04WXFHZ0dXaW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9Imh0dHA6Ly93d3cu
am9lcmNoLm9yZy9nby93LmdpZiIgQk9SREVSPSIwIkFMVD0ibyI+PC9BCj48QSBIUkVGPSJ2
NEJDLUpxcVFNOFlxR2dHV2luSG9IcWdVRVFxV2dtQzE/b28iPjxJTUcgU1JDPSJodHRwOi8v
d3d3LmpvZXJjaC5vcmcvZ28vNi5naWYiIEJPUkRFUj0iMCJBTFQ9Ii4iPjwvQQo+PEEgSFJF
Rj0idjRCQy1KcXFRTThZcUdnR1dpbkhvSHFnVUVRcVdnbUMxP29vIj48SU1HIFNSQz0iaHR0
cDovL3d3dy5qb2VyY2gub3JnL2dvL3cuZ2lmIiBCT1JERVI9IjAiQUxUPSJvIj48L0EKPjxB
IEhSRUY9InY0QkMtSnFxUU04WXFHZ0dXaW5Ib0hxZ1VFUXFXZ21DMT9vbyI+PElNRyBTUkM9
Imh0dHA6Ly93d3cuam9lcmNoLm9yZy9nby81LmdpZiIgQk9SREVSPSIwIkFMVD0iLiI+PC9B
Cj4KPFA+ClN3aXRjaCB0byA8QSBIUkVGPSJ2NEJDK0pxcVFNOFlxR2dHV2luSG9IcWdVRVFx
V2dtQzE/byI+aGlnaCBxdWFsaXR5PC9BPiBncmFwaGljcy4KPFA+ClN0YXJ0IGEgPEEgSFJF
Rj0iaHR0cDovL3d3dy5qb2VyY2gub3JnL2dvL2pvZ28uaHRtbCI+bmV3IGdhbWU8L0E+Lgo8
SFI+PFA+PEEgSFJFRj0iaHR0cDovL3d3dy5qb2VyY2gub3JnL2pjLyI+SiZvdW1sO3JnIEN6
ZXJhbnNraTwvQT4KPC9CT0RZPgo8L0hUTUw+Cg==
--PART-BOUNDARY=.1980227150824.ZM21322.ucc.su.OZ.AU--
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
From: Heikki Levanto <heikki@xxxxxxxxxxxxxxxxx>
Message-Id: <199802270805.JAA08445@xxxxxxxxxxxxxxxxx>
Subject: Life status
To: computer-go@xxxxxxxxxxxxxxxxx
Date: Fri, 27 Feb 1998 09:05:18 +0100 (MET)
Content-Type: text
Reply-To: computer-go@
X-Sequence: 35
Precedence: list
To get the notation discussion down to more concrete levels, may I ask what
kind of life-and-death values you all implement (or think of implementing)?
Something like
absolutely dead, can not be saved at all
dead, but can be saved if I get two moves in a row
dead, can be used for aji here or there
dead, but takes a long time to kill (an eye and many liberties)
...
unsettled ...
...
absolutely alive, can not even be threatened
What do you think, how many graduations should one have? Should unsettled
groups have two values, depending on who plays first, or should their status
be compressed in one value?
Do you keep similar values for both groups and strings, and/or other level
constructions? (what? Territories? spheres of influence?)
Thanks in advance
Heikki Levanto
--
Heikki Levanto LSD - Levanto Software Development <heikki@xxxxxxxxxxxxxxxxx>
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Message-Id: <v03130303b11c74a2383e@[128.252.148.143]>
In-Reply-To: <980227150825.ZM21322@xxxxxxxxxxxxxxxxx>
References: "P.J.Leonard" <P.J.Leonard@xxxxxxxxxxxxxxxxx> "Re: Notation" (Feb 24,
12:07pm) <199802240849.JAA18252@xxxxxxxxxxxxxxxxx>
<34F2B816.52BF@xxxxxxxxxxxxxxxxx>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 27 Feb 1998 07:48:39 -0600
To: computer-go@xxxxxxxxxxxxxxxxx
From: Yongming Sun <ysun@xxxxxxxxxxxxxxxxx>
Subject: Re: Notation
Reply-To: computer-go@
X-Sequence: 36
Precedence: list
unsubscribe
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
From: Heikki Levanto <heikki@xxxxxxxxxxxxxxxxx>
Message-Id: <199802271436.PAA17098@xxxxxxxxxxxxxxxxx>
Subject: Re: Life status (fwd)
To: computer-go@xxxxxxxxxxxxxxxxx
Date: Fri, 27 Feb 1998 15:36:21 +0100 (MET)
Content-Type: text
Reply-To: computer-go@
X-Sequence: 37
Precedence: list
P.J.Leonard mailed this to me instead of the mail. Another vote for the
REPLY-TO header!
Heikki Levanto wrote:
>
> To get the notation discussion down to more concrete levels, may I ask what
> kind of life-and-death values you all implement (or think of implementing)?
>
> Something like
> absolutely dead, can not be saved at all
> dead, but can be saved if I get two moves in a row
> dead, can be used for aji here or there
> dead, but takes a long time to kill (an eye and many liberties)
> ...
> unsettled ...
> ...
> absolutely alive, can not even be threatened
>
> What do you think, how many graduations should one have? Should unsettled
> groups have two values, depending on who plays first, or should their status
> be compressed in one value?
Why compress information.
> Do you keep similar values for both groups and strings, and/or other level
> constructions? (what? Territories? spheres of influence?)
At the moment . .
I work out the status of a string along the lines Dave Fotland suggests
with and without a pass. This results in 2 searches. The outcome of each
search
can be PROVEN (lives) REFUTED (dead) or UNDECIDED (with associated
proof/refute numbers).
All this information is stored (4 numbers) for each string.
A STABLE string has the same status if both searches yield the same
result.
The status of stable string is not effected by either player making a
move so to a first
order approx it is not worth making a move.
I define a string UNSTABLE if the pass and first move search return
different results
and it is in the players advantage to move first (otherwise it is SEKI).
I have got the proof numbers for 2 searches available to the rest of the
program.
This inforamtion is bassed on local tactical searching. In which the
move suggesters
are liberties, second order liberties and liberties of touching hostile
strings (if they
have the same or less liberties than the focus string).
This scheme is intended to do the analysis of capturing races ladders
and nets.
I can see the intention of alive if I get 2 moves (this must be related
to the aji scheme ?).
The generalisation of this idea would be to have a template e.g.
blackmoves
blackmoves
[white then black] x N
whitemoves
such information would certainly be of use if the program was clever
enough to use it :-)
Absolutely alive should be worked out but I have not done so yet.
---
At present I have a very simple influence function that defines an area
of white influence
and black influence (these may overlap). I have available these areas
and the size.
It was pointed out that there are degrees of influence but I have no
plans to attempt
to quantify this until I can see the weaknesses in my current system.
cheers Paul.
--
Heikki Levanto LSD - Levanto Software Development <heikki@xxxxxxxxxxxxxxxxx>
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Message-Id: <01BD4368.E0092F40@CALEB>
From: claggett@xxxxxxxxxxxxxxxxx (Claggett, Jonathan)
To: "'computer-go@xxxxxxxxxxxxxxxxx'" <computer-go@xxxxxxxxxxxxxxxxx>
Subject: unsubscribe
Date: Fri, 27 Feb 1998 10:17:09 -0600
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: computer-go@
X-Sequence: 38
Precedence: list
unsubscribe
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Date: Fri, 27 Feb 1998 17:30:27 +0100
Message-Id: <199802271630.RAA15708@xxxxxxxxxxxxxxxxx>
From: Jean-loup Gailly <jloup@xxxxxxxxxxxxxxxxx>
To: claggett@xxxxxxxxxxxxxxxxx (Claggett, Jonathan)
Cc: computer-go@xxxxxxxxxxxxxxxxx
Subject: Re: unsubscribe
In-Reply-To: <01BD4368.E0092F40@CALEB>
References: <01BD4368.E0092F40@CALEB>
X-Mailer: VM 6.22 under 19.15 XEmacs Lucid
Reply-To: Jean-loup Gailly <jloup@xxxxxxxxxxxxxxxxx>
X-Sequence: 39
Precedence: list
> unsubscribe
Please please stop this! I sent the following a few days ago:
To leave the mailing list, send the message "unsubscribe computer-go"
(without the quotes) to <computer-go-request@xxxxxxxxxxxxxxxxx>.
Do not send your message to the whole list. Thanks.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
More information on the computer-go mailing list is available at
http://www.hsc.fr/computer-go/
The previous mailing list automatically filtered out the unsubscribe
request. The new list owner is working hard to manage the list but
it may take him a little more time to set up such filters. (I'm not
the list owner. The list owner is computer-go-owner@xxxxxxxxxxxxxxxxx .)
I apologize for having to send this message to the whole list but
for the moment there is no other way to stop an avalanche of
unsubscribe requests.
Jean-loup
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Message-Id: <3.0.5.32.19980228114633.007de100@xxxxxxxxxxxxxxxxx>
X-Sender: fotland@xxxxxxxxxxxxxxxxx
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Sat, 28 Feb 1998 11:46:33 -0800
To: Heikki Levanto <heikki@xxxxxxxxxxxxxxxxx>
From: David Fotland <fotland@xxxxxxxxxxxxxxxxx>
Subject: Re: Life status
Cc: computer-go@xxxxxxxxxxxxxxxxx
In-Reply-To: <199802270805.JAA08445@xxxxxxxxxxxxxxxxx>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: computer-go@
X-Sequence: 40
Precedence: list
At 09:05 AM 2/27/98 +0100, you wrote:
>
>To get the notation discussion down to more concrete levels, may I ask what
>kind of life-and-death values you all implement (or think of implementing)?
>
>Something like
> absolutely dead, can not be saved at all
> dead, but can be saved if I get two moves in a row
> dead, can be used for aji here or there
> dead, but takes a long time to kill (an eye and many liberties)
> ...
> unsettled ...
> ...
> absolutely alive, can not even be threatened
Many Faces of Go has 23 values:
# define DEAD 25
# define LIFEUNUSED 24
# define WEAK_GROUP 23
# define VERY_WEAK 23
# define MUST_BE_DEAD 22
# define LOOKS_DEAD 21
# define LOSE_SEMEAI 20
# define WEAK 19
# define WEAK_POTENTIAL 18
# define WEAK_SEMEAI 17
# define WEAK_LIMP 16
# define UNSETTLED 15
# define WEAK_KO 15
# define UNSETTLED_RUN 14
# define SEMEAI 13
# define UNSETTLED_DEAD 12
# define UNSETTLED_THREATENED 12
# define RUNNING_FIGHT 11
# define STRONG_KO 10
# define STRONG_SEMEAI 9
# define UNSETTLED_LIMP 8
# define ALIVE 7
# define RUN_NO_EYES 7
# define RUN_OR_LIVE 6
# define WINS_SEMEAI 5
# define SEKI 4
# define MIAI 3
# define BARELY_ALIVE 2
# define VERY_ALIVE 1
# define STRONG_MIAI 1
# define HAS_TWO_EYES 1
# define NEW_ALIVE 0
unsigned char gralive[NUMGROUPS]; /* aliveness of group (0-25)
HERE DOWN ARE DEAD
25 - tactically captured unconditionally
24 - unused.
23 - Temp used for weak groups undecided yet
22 - No eyespace or potential and nbrs all alive
21 - probably dead some eye space or potential, nbrs alive
20 - in semeai loses
HERE DOWN ARE WEAK - PROBABLY WILL DIE
19 - no running ability, weak nbrs and some eye potential)
18 - can't run, lots of eye potential, only one eye
has aji to live, or can be used as ko threats
17 - in a semeai. behind - aji for later
16 - poor running ability - can't live in one move
HERE DOWN ARE UNSETTLED
15 - ko for life, must capture ko, then fill to live
14 - must run away to live - adjacent enemy groups settled
13 - in a semeai. unsettled
12 - surrounded, can live or die in one move
12 - would be alive, but tactically threatened
11 - running fight - have to run to live, and adjacent group also has to run
10 - ko for life, fill ko to live
9 - in a semeai. Ahead or temporary seki
8 - unsettled - can live in one move or limp away
HERE DOWN ARE ALIVE (or settled for now)
7 - can run away easily, no eyes
6 - can run away easily, one eye
needs two moves to make second eye
6 - can live in one move or run easily
5 - Alive because wins semeai
4 - at least a seki - may be actual seki, or temporary seki
3 - miai for barely space for two eyes (dangerous)
2 - barely territory for two eyes (dangerous)
HERE DOWN ARE VERY ALIVE
1 - miai for lots of eye space - 3 or more ways to make
second eye
1 - absolutely unconditionally alive - two small eyes
or lots of territory
0 - temporary value for newly created group
*/
>
>What do you think, how many graduations should one have? Should unsettled
>groups have two values, depending on who plays first, or should their status
>be compressed in one value?
I'd like to have a few more gradations. It helps to have different values
for exact evaluations and uncertain evaluations, to direct attention when
reading.
>
>Do you keep similar values for both groups and strings, and/or other level
>constructions? (what? Territories? spheres of influence?)
For strings, I only keep more basic values, such as liberty count, lists
of liberties, enemy nbr strings, connections, etc.
Each string records its tactical status (captured, unsettled, tactically
safe, ko, etc.)
Territory is evaluated on a point by point basis. I have no concept of
a region of territory. Each point has an integer value for territory.
Enclosed or partially enclosed regions are recorded as eyes to help life and
death. There are several classifications of eye shapes:
# define NOEYE 0
# define ONEPOINTEYE 1 // one point fully surrounded
# define TWOPOINTEYE 2 // 2 pts fully surrounded
# define DEADEYE 3 // dead enemy stones, any shape
# define THRTEYE 4 // threatened enemy stones, any shape
# define BIGEYE 5 // one point surrounded on 3 sides, up to 4 of them sharing
// a common open point (+ shape, etc)
# define LINEEYE 6 // line of points any length or shape, closed on both ends
# define FOURPTBLOCKEYE 7 // 4 in a block, completely surrounded
# define OPENLINEEYE 8 // line of points, any shape, open on either or both
ends
# define CORNEREYE 9 // any big shape that includes the corner
# define NEAREDGEEYE 10 // point surrounded on 2 sides, on second line
# define VERYBIGEYE 11 // any other large, patially or fully surrounded area
This is not the eye classification I would use if started again, but
reflects the
order that I added new code to evaluate eye shapes. My go programming
philosophy
has always been to try things and invent as I find problems, not to try to
figure the
best framework first :)
David Fotland
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------