I've coded my algorithm for removing dead stones after game is over.

[Robert Maas, http://tinyurl.com/uh3t]

* Background:

In 1996, using Macintosh Allegro Common Lisp, on my Mac Plus, I
wrote primitives for maintaining a Go position and generating legal
moves and playing moves, and wrote a crude version of my idea for
playing random-symmetric moves (pick player at random, then pick a
legal move by that player at random) until the game is totally over
(all dead stones have actually been captured, so that it's now
possible for the computer to correctly count the score).

The purpose of such an algorith, if I could get it to work
reliably, would be to generate Monte Carlo estimates of the score
of the game at any point, and use that to guide a good-move
lookahead.

Unfortunately such a simple algorithm (playing any legal move
whatsoever) allows live groups to fill their own eyes and thus turn
dead, so the process never ends. I had some ideas for restricting
moves to be "reasonable", but they weren't sufficient for avoiding
the problem while still allowing play to very end of game. I also
didn't have a simple algorithm for telling the difference between
true eyes (which should not be filled) and false eyes (needed
connection points, which *should* be filled to avoid capture of an
outlying eyeless group).

Since then, from time to time, I've thought about a good rule for
restricting moves to avoid filling one's own eyes, and avoid
breaking seki, and not putting a large group into self-atari, but
allowing sacrifice of dead-eye-shape to kill surrounding one-eyed
group. I've also, assuming I could solve that problem thought about
how to keep statistics of various sorts to guide the move generator
to estimate how valuable moves would be even before actually trying
that move. In particular, on 2010.Apr.24 I wrote up notes about
what statistics I would have the program build. But I was busy on
another project (TinyURL.Com/NewEco) so I didn't have time to
implement anything.

Then 2012.Oct I finally figured out an algorithm for distinguishing
true eyes from false eyes, and worked out an algorithm I thought
would generate *only* reasonable moves, and wrote it up. Here is
the final version of spec pruning the list of all empty points down
to just the reasonable moves:

- If illegal move (suicide), then NO.
- If capture, then YES.
- If fill one-point true-eye, then NO.
- If self-atari:
- If self dead-shape (rabbity-six or less) .AND. at least one opposing group
is put into atari with the remaining liberty shared with this group,
then YES; (Toward dead-eye-shape kill, or snapback, see examples 1,2.)
- Else NO. (Don't ruin a seki by giving other group two eyes, and don't
sacrifice dead shape if opponent can capture it and have one
eye where the other liberty is located plus one eye where the
dead-shape was killed, see example 3.)
- All other moves YES. (Toward killing dead enemy stones/groups inside
already-live group, and reducing all territory inside already-live group
to nothing except one-point eyes, whereupon no further moves will be
considered and thus algorithm will terminate.)

Example 1 (upper-left corner):
A B C D E F G H J K
19 X X X - O - X X - X ...
18 X O X X X X O X X X ...
17 X O O O O O O X - X ...
16 O O - O - O O X X X ...
15 - - O O O O - X X X ...
.......................
White plays F19, putting dead-2-shape in atari, a two-step
snapback. If black plays D19 to kill, black plays F19 again,
creating a direct snapback. If black plays E19 to kill, white plays
F19 again, killing the large black group in corner.

Example 2 (upper-left corner):
A B C D E F G
19 X X O O X - X ...
18 X X X O X X X ...
17 - - O O X - X ...
16 O O O X X X - ...
15 X X X X - - - ...
.................
Black plays B17, making dead-rabbity-6-shape in self-atari. If
white takes it, black plays B18, then builds that stone up to
dead-P-5-shape, in self-atari again. If white takes it, black plays
B18 again, then builds that stone up to dead-square-4-shape, in
self-atari again. If white takes it, black plays B18 again, then
builds that stone up to dead-3-shape, in self-atari again. If white
takes it, black plays B18 again, then builds that stone up to
dead-2-shape, in self-atari again. If white takes it, black plays
B18 again, which is dead-1-shape in atari already. If white takes
it, black plays B18 again, killing white's group.

Example 3 (upper-left corner):
A B C E F G H J
19 X - O O O X X - ...
18 - O - O X X X X ...
17 O O O X - X - X ...
16 X O O X X X X - ...
15 X X X X - - X X ...
...................
If X plays at B19, he puts 4 white stones around C19 in atari, but
unlike the first two examples, the in-atari group doesn't share a
liberty with the cutting stones.

If white defends from the atari by playing C18 to connect to the
other group, white dies, so the dead-eye-shape throw-in worked.

Instead, white should capture the cutting stones by playing at A18,
thus having two separate eyes, one where the cutting stones were
killed, and one at C18 where the atari'd stones had that liberty.
Having that liberty *separate* from the liberty of the cutting
stones, means he doesn't fill his liberty when he kills the cutting
stones, and it also means the liberty is separate from the eye
created by the killed stones.


* News:

This past Saturday (2012.Nov.24) I finally started to extract the
useful parts from the old MACL program, then upgrade the code to
include my new algorithm (not described in this article) for
distinguishing true eyes from false eyes, and finally to include
the above algorithm for distinguishing possibly-useful moves (YES
per the above spec) from moves that are obviously worthless or
actually bad (NO per the above spec), and a program loop that
repeatedly selected player at random then stepped through the legal
moves at random, playing the first move that satisied YES in the
above spec, and by Sunday night I had it all working. Experiments
late that night into Monday morning showed that in EVERY case the
algorithm reached a stable state, never self-destructing a group
that was absolutely alive (two eyes) and never breaking a seki,
always stopping when all eyes have been reduced to one-point eyes
and all sekis have been reduced to minimal liberties.

Note that if a live group isn't solidly connected, my algorithm
might by chance give the opponent several moves in a row, allowing
the live group to be cut apart and piecemeal captured. Also with a
seki that has extra outside liberties, my algorithm might by chance
give the opponent several moves in a row, filling outside liberties
of the opponent's group, changing the situation from a seki to a
semeai where the player with the extra moves can now capture the
other player. Also, if there are necessary connection points (false
eyes) not yet filed, my algorithm might by chance give the opponent
several moves in a row, filling dame to put the eyeless group into
atari, then playing at the connection point to kill the group.

In any of those kinds of situations, my algorithm will sometimes
make connection points and properly reduce liberties of a seki so
that it remains a seki, thus achieving the correct result, while
sometimes my algorithm will allow several moves in a row by a
player, allowing tactically-alive stones to be killed. By running
the algorithm repeatedly, we can collect a Monte Carlo sample o
possible end results, which always includes the tactically correct
result somewhere in the range of scores, showing that the game
isn't yet absolutely finished even if any good human player can
finish it correctly.

Thus I tentativly claim for my algorithm that if the game has
already been played out (under Chinese or simplified area rules, or
during second phase of Lasker-Maas rules) such that:
- All dead stones have been reduced to shape + surrounding empty
space where they cannot possibly form two eyes or seki even if
given unlimited sequential moves.
- All false eyes and other necessary connection points have been
filled, so that live groups become *absolutely* alive
(impossible to kill even if opponent has unlimited sequential
moves to try to kill the group).
- All dame have been filled.
then my algorithm will always kill dead stones and reduce each eye
to a one-point eye, without ever filling one's own eyes, and thus
achieve the same Chinese/area score every time, which is the
tactically correct score.

Furthermore, if you are playing against the computer, if you pass
before the above critera have been satisfied, my algorithm will
give the computer the ability to continue to make additional moves
which might steal some points from you (killing some of your live
stones or rescuing some of its own stones) if you fail to respond
correctly, as well as make safety plays for its own groups, as well
as take dame if any are unfilled (you should have taken them
*before* you passed, you definitely lose points in this case if
there are an odd number of dame or if you fail to match the
computer at filling half the dame each), until the above criteria
are finally satisfied, at which point it will be able to count the
score.


* Future suggestions:

If any Internet Go server were to switch to Lasker-Maas rules,
instead of having players manually mark dead groups (as currently
done on IGS, which can cause nasty disputes if somebody marks a
live group as dead, and in any case it's a burden on the players),
then my algorithm could be used during stage 2 to (1) ask players
to please fill dame and fill connection points etc. to satisfy the
above criterion, actually telling the player which groups are in
danger of being captured if the opponent gets unlimited sequential
moves, then (2) automatically remove exactly the dead stones
without any possible mistake/dispute.

One easy user interface would be to show absolutely-alive stones in
upper case, and all other stones (either absolutely dead, or
tactically alive but needing connection points filled) in lower
case, so the players simply look at lower-case stones to see what
needs playing to make the live stones all upper case. This
automatic annotating of stones by text case (in verbose mode) would
begin as soon as the players pass 3 times consecutively to switch
from stage 1 (play for best score) to stage 2 (prove what's alive
and what'd dead without changing the score).

Google-groups-search-key: imtrgfdi

[Robert Jasiek]

Robert Maas, http://tinyurl.com/uh3t wrote:
>In 1996 [...]

>The purpose of such an algorith, if I could get it to work
>reliably, would be to generate Monte Carlo estimates

Does this mean that you discovered MC for go years before everybody
else? I thought that MC for go was discovered in the 2000s.

>the final version of spec pruning the list

Why do you not state a condition for illegal repetition (ko)? Do you
treat them as YES for the sake of generating random plays and detect
ko bans only later?

>of all empty points down
>to just the reasonable moves:
>
>- If illegal move (suicide), then NO.
>- If capture, then YES.
>- If fill one-point true-eye, then NO.
>- If self-atari:
> - If self dead-shape (rabbity-six or less) .AND. at least one opposing group
> is put into atari with the remaining liberty shared with this group,
> then YES; (Toward dead-eye-shape kill, or snapback, see examples 1,2.)
> - Else NO. (Don't ruin a seki by giving other group two eyes, and don't
> sacrifice dead shape if opponent can capture it and have one
> eye where the other liberty is located plus one eye where the
> dead-shape was killed, see example 3.)
>- All other moves YES. (Toward killing dead enemy stones/groups inside
> already-live group, and reducing all territory inside already-live group
> to nothing except one-point eyes, whereupon no further moves will be
> considered and thus algorithm will terminate.)

Many thanks!

Do you suggest a definition for "self dead-shape"? Citing from
Capturing Races 1, there are related definitions (the "eye" defined
there is not a general definition of eye but defines a "semeai-eye"):

"For semeais, an _eye_ is a region so that
- it consists of connected intersections,
- it is surrounded by one player's stones of essential strings,
- it does not contain any stone of an essential string,
- if the player and his opponent play only within the region and do
not remove any surrounding stone, the player moving first can
necessarily fill all but one intersection and
- if the player and his opponent play only within the region, the
player moving _second_ cannot necessarily permanently partition it
into at least two regions."

"An eye is _stable_ if, supposing the player surrounding the eye and
his opponent play only within the eye's region, the player moving
_first_ cannot necessarily permanently partition it into at least two
regions."

"An eye is _unstable_ unless it is stable."

"An eye is _hot_ if
- it is unstable and
- all surrounding strings are in atari."

(Hot is then used to help defining a distinction of strong and weak
eyes.)

>algorithm (not described in this article) for
>distinguishing true eyes from false eyes,

Can you publish that algorithm, please?

>and finally to include
>the above algorithm for distinguishing possibly-useful moves (YES
>per the above spec) from moves that are obviously worthless or
>actually bad (NO per the above spec),

How about a proof?

>Experiments
>late that night into Monday morning showed that in EVERY case the
>algorithm reached a stable state, never self-destructing a group
>that was absolutely alive (two eyes) and never breaking a seki,
>always stopping when all eyes have been reduced to one-point eyes
>and all sekis have been reduced to minimal liberties.

Experiments are good - proof is better:)

>[...]By running

>the algorithm repeatedly, we can collect a Monte Carlo sample o
>possible end results, which always includes the tactically correct
>result somewhere in the range of scores,

Ok.

>Thus I tentativly claim for my algorithm that if the game has
>already been played out (under Chinese or simplified area rules, or
>during second phase of Lasker-Maas rules) such that:
>- All dead stones have been reduced to shape + surrounding empty
> space where they cannot possibly form two eyes or seki even if
> given unlimited sequential moves.
>- All false eyes and other necessary connection points have been
> filled, so that live groups become *absolutely* alive
> (impossible to kill even if opponent has unlimited sequential
> moves to try to kill the group).
>- All dame have been filled.
>then my algorithm will always kill dead stones and reduce each eye
>to a one-point eye, without ever filling one's own eyes, and thus
>achieve the same Chinese/area score every time, which is the
>tactically correct score.

Good. Proof is needed:)

>Furthermore, if you are playing against the computer, if you pass
>before the above critera have been satisfied, my algorithm will
>give the computer the ability to continue to make additional moves
>which might steal some points from you (killing some of your live
>stones or rescuing some of its own stones) if you fail to respond
>correctly, as well as make safety plays for its own groups, as well
>as take dame if any are unfilled (you should have taken them
>*before* you passed, you definitely lose points in this case if
>there are an odd number of dame or if you fail to match the
>computer at filling half the dame each), until the above criteria
>are finally satisfied, at which point it will be able to count the
>score.

Ok.

>If any Internet Go server were to switch to Lasker-Maas rules,
>instead of having players manually mark dead groups (as currently
>done on IGS, which can cause nasty disputes if somebody marks a
>live group as dead, and in any case it's a burden on the players),
>then my algorithm could be used during stage 2 to (1) ask players
>to please fill dame and fill connection points etc. to satisfy the
>above criterion, actually telling the player which groups are in
>danger of being captured if the opponent gets unlimited sequential
>moves, then (2) automatically remove exactly the dead stones
>without any possible mistake/dispute.

Good idea. Wouldn't it be straightforward to adopt your algorithm to
other, area scoring rulesets?

[Robert Maas, http://tinyurl.com/uh3t]

> From: Robert Jasiek <jas...@snafu.de>
Ah, exactly the best person to discuss this topic, since you have
been publishing the FAQ including rulesets and also you have posted
some newsgroup articles about theoretical questions and algorithms,
and several years ago you seemed to appreciate my Lasker-Maas
ruleset, although I was disappointed the current rules-FAQ doesn't
mantion them, presumably because they've never been used for an
official tournament/match nor any online server, and I haven't even
implemented them myself in any (informal) server or demonstrated
program.

Before I respond to your article, let me include an update on my
current random-symmetric play-to-end software: Since a week ago
when I achieved the first working version, I've made these
upgrades:
- I now check for playing into cul-de-sacs which can be "obviously"
converted into an eye if the entrance were played instead. Such
moves now give NO as to permission for play in random-symmetric
algorithm. In particular two-point-eyes don't get half-filled
(which just means reaching a final position takes fewer moves),
two-point false eyes get filled only at the connection points, not
at the already-connected points, and multi-point linear eyes never
get filled at the endpoints, only in the middle points. This
doesn't change the fact that the algorithm will always terminate,
but it significantly improves the quality of truly random, making
it less frustrating for the kibitzer.
- I've changed the random-symmetric algorithm to have a parameter
as to the probability that black gets next move, instead of always
50% each player. This allows me to bias the sample according to one
player stronger than the other. By using a range of such
probabilities from nearly 0 to nearly 1, I can effectively see what
happens if one or the other player gets all the moves he could
possibly want, and thus kill any tactically alive group that isn't
absolutely connected with absolutely solid eyes.
- I have a simple loop that alternates plays, respecting the
situational super-ko rule. After showing the board, before asking
the next player to choose a move, it plays-to-end with very strong
bias of pblac=0.01 and pblack=0.99 to detect (almost always) the
absolutely best each player could achieve if the other player
decides to pass perpetually. I use it as a reminder that there are
still some connections needed before the random lookahead is
guaranteed to compute the correct score. As soon as the low bound
and upper bound are equal, it offers to end the game right now
without further removing of dead stones, because it *knows* what's
alive and what's dead already.
- Using Monte Carlo sampling (random play to end) with pblack
ranging over several values from near 0 to near 1, I get a
sampleset that estimates the range of end results. Using that, I
wrote a playing program that makes "safe" moves by making the legal
move whereby the Monte Carlo samples after just that one move (no
deeper lookahead except the random-play-to-end itself) have worse
case possible result as least-bad as possible.
- Using the random-play-to-end, with a wide range of pblacks,
looking at the actual final boards (with territory filled) rather
than the score obtained on the whole board: For each point on the
original board, tabulate among all the end-boards (with territory
filled), +1 for that board-point belonging to black at the end, -1
for that board-point belonging to white at the end, 0 for that
board-point being unfilled due to seki, then scale those
per-board-point totals to a range of 1 to 9 so that they can be
printed on the empty spaces. For example, with this original board:

A B C D E F G

7 - X - - - - X 7
6 X X X - X X - 6
5 - X - X - X - 5
4 X X - X X O - 4
3 O O - O O - - 3
2 O - O - - O - 2
1 - O O - O - - 1

A B C D E F G

One of the runs of this who-might-control-which-points-of-board
gives this whole-board matrix:
((9 9 8 7 7 7 7)
(9 9 9 7 8 8 7)
(9 9 7 8 8 8 7)
(9 9 5 8 8 3 6)
(1 1 4 2 2 3 5)
(1 1 1 2 2 2 3)
(1 1 1 2 2 2 3))
which when embedded into only the empty points, gives this view:

A B C D E F G

7 9 X 8 7 7 7 X 7
6 X X X 7 X X 7 6
5 9 X 7 X 8 X 7 5
4 X X 5 X X O 6 4
3 O O 4 O O 3 5 3
2 O 1 O 2 2 O 3 2
1 1 O O 2 O 2 3 1

A B C D E F G

Now to answer your questions:

> >In 1996 [...]
> >The purpose of such an algorith, if I could get it to work
> >reliably, would be to generate Monte Carlo estimates
> Does this mean that you discovered MC for go years before everybody
> else? I thought that MC for go was discovered in the 2000s.

I thought of the idea, and wrote some code, but realized my
algorithm wasn't working, and didn't have a name for it at that
time, later heard of some new Go program that claimed to use Monte
Carlo methods, but from what I could tell from online descriptions
it wasn't like mine. Since mine wasn't practical (player with live
group tended to fill his own eyes, turning a live group to a
one-eyed group, at which point the opponent killed it), it didn't
"terminate", and I didn't have an easy way to detect which true
eyes shouldn't be filled and which false eyes should be filled, I
had two reasons not to brag about having the idea first, that I
didn't have it working at all usefully, and thus I had no way to
collect evidence that if it were made to work it'd actually give
good results.

The key difference between my idea and what I read about on the net
that others did is that my idea is to randomly choose who gets to
move next, rather than respecting the alternating play, thus
there's no need to worry about the ko rule (see my answer to you
below), no need to synchronize ko captures with ko threats, no need
to even care about ko threats, just treat any ko at this point as
"random winner".

So yes I was one of the people who thought of the general idea of
"Monte Carlo" sampling of how a game might end several years before
anybody had anything working well enough to publish reports of it.
As to who got such a general idea very first, I have no idea.

> Why do you not state a condition for illegal repetition (ko)? Do
> you treat them as YES for the sake of generating random plays and
> detect ko bans only later?

My key realization circa 1996 was that when randomly choosing who
plays next in Monte Carlo lookahead, you really don't need to care
about any ko restriction, because the following two random
sequences are identical in result:
- Black captures ko, white retakes ko, white fills ko.
- White fills ko.
Because we're choosing not just points on board but who gets to
play next at random, if a ko is the only playable point available
my algorithm will oscillate the ko back and forth until one of the
players randomly gets two moves in a row to fill it. Because my
algorithm is *not* supposed to choose the best move in alternating
play, not even close, because it's choosing *random* moves, some
samples will have black winning ko and some will haVe white winning
ko, thus correctly providing an interval around whatever the
tactically correct result would be with perfect alternating play.

The primary purpose of my algorithm is to correctly play out which
groups are alive and which are dead, *after* players have decided
the game is over and have filled dame and have made a few extra
moves inside their own territory to make absolutely sure their live
groups won't be killed if they now start passing and letting the
other player get several moves in a row to try to kill them.
Likewise remove all possibility of opponent rescuing his dead
stones, by *you* making extra moves to spoil any possible eye
shape, so that if you pass lots of consecutive times he still can't
make his dead stones come to life.

So if the game is truly **over**, all live groups solidly
connected, all dead groups totally eye-shape-spoiled, there will be
no possible sequence of legal moves that change the outcome, except
if a player fills his own eyes, which my algorithm avoids.

And if the game is not yet truly over, if there are still some
needed connection points, my algorithm can play against the human
to force him to make connections, and if there's any chance for a
dead group to make eyes, the computer can try to make eyes forcing
the human to truly kill it absolutely and forever.

And if the game is not yet over at all, my algorithm will give a
rough idea what might happen if one or the other players falls
asleep or has a mental lapse or is exhausted and in byo yomi,
showing how the winner isn't yet absolutely determined under such
mental-lapse situations. (Remember that Honinbo game earlier this
year when a player in byo yomi failed to correctly respond to a
threat against his tactically live group, allowing the opponent to
kill it.)

So if the game is truly *over* as defined above, any ko that might
occur is totally irrelevant, the invading stones are dead whether
they win the ko or not, so randomly playing out the ko, ignoring
the rule against repetition, gives the correct result in every
case.

I'm rather proud of my realization back then (circa 1996) that, for
those reasons, the ko rule can be ignored when using my (at that
time only proposed, but now perfected) algorithm.

> >- If illegal move (suicide), then NO.
> >- If capture, then YES.
> >- If fill one-point true-eye, then NO.
> >- If self-atari:
> > - If self dead-shape (rabbity-six or less) .AND. at least one opposing group
> > is put into atari with the remaining liberty shared with this group,
> > then YES; (Toward dead-eye-shape kill, or snapback, see examples 1,2.)
> > - Else NO. (Don't ruin a seki by giving other group two eyes, and don't
> > sacrifice dead shape if opponent can capture it and have one
> > eye where the other liberty is located plus one eye where the
> > dead-shape was killed, see example 3.)
> >- All other moves YES. (Toward killing dead enemy stones/groups inside
> > already-live group, and reducing all territory inside already-live group
> > to nothing except one-point eyes, whereupon no further moves will be
> > considered and thus algorithm will terminate.)
> Many thanks!

Thanks for what, for so clearly stating my rule for permitting or
not permitting a legal move in my algorithm?

> Do you suggest a definition for "self dead-shape"? Citing from
> Capturing Races 1, there are related definitions (the "eye" defined
> there is not a general definition of eye but defines a "semeai-eye"):
> "For semeais, an _eye_ is a region so that
> - it consists of connected intersections,

Ok so far.

> - it is surrounded by one player's stones of essential strings,

Huh? This sounds like jibbeish.

> - it does not contain any stone of an essential string,

More apparent jibberish.

> - if the player and his opponent play only within the region and do
> not remove any surrounding stone, the player moving first can
> necessarily fill all but one intersection and
> - if the player and his opponent play only within the region, the
> player moving _second_ cannot necessarily permanently partition it
> into at least two regions."

This is too complicated for my purpose, requiring actual minmax
alternating-play lookahead just to define an eye. My algorithm for
testing a one-point-eyeshape (i.e. ponnuki, or analagous 3-stone
edge shape, or 2-stone corner shape) as to whether it's a true eye
or a false eye, assumes all eyes have already been reduced to
one-point eyes. If some eyes are larger, Monte Carlo play-to-end
will sometimes play in the wrong places and fill what is tactically
a one-point-eye because of some larger eye elsewhere looking like a
way to separate the groups. But some other Monte Carlo samples will
happen to play better, showing a range of results, some correct
some wrong, but with the correct result somewhere within the span
of samples. With my restricted question, the question can be
answered with a static analysis (plus one trick that I'm keeping
secret for now), no lookahead needed to *define* what's a one-point
eye and what's a one-point false eye.

One caveat: Before I added the restriction on filling cul-de-sacs,
every eye truly reduced to one or more one-point eyes before the
random-symmetric play ended. At such a time, my definition of true
eye vs. false eye is (to my strong belief) absolutely correct, thus
when only one-point-eyeshapes remain, the false ones will be filled
(or captured if the other player randomly gets an extra move) while
every one of the true eyes will be preserved unfilled. But at an
earlier stage, while larger eyes still exist, my algorithm might
mistakenly fill a tactically-true eye because my algorithm treats
it as a false eye instead. I haven't yet done enough analysis of
this problem to decide whether it's a serious problem or not. In
particular, if two not-yet-connected strings share exactly two
eyes, one a one-point eye and one a two-point eye, all three empty
spaces are playable, so there's a 2/3 chance the two-point eye will
be half-filled yielding two one-point eyes wherey my algorithm will
correct leave both unfilled, but a 1/3 chance the one-point eye
will be filled instead, self-killing a formerly live group. With
only 1/3 chance of the wrong move in such a case, and Monte Carlo
methodology producing several random samples, it's very unlikely
the one wrong move will be selected for EVERY sample, so on first
thought it seems not to be a problem to worry about. With larger
eyes, the chance of randomly filling the one point eye instead of
reducing the multi-point eye is even smaller, but there might be a
case I haven't thought about that cause a serious problem.

(snipped more definition of eye that requires lookahead hence is
not suitable for my purposes)

> >algorithm (not described in this article) for
> >distinguishing true eyes from false eyes,

(Note this algorithm is *only* in the case where all eyes are one
point each.)

> Can you publish that algorithm, please?

I am not aware of any professional journal that would be willing to
publish such algorithm, and I'm not willing to post on the Web and
thus lose all my rights, so for the moment I'll keep it as a "trade
secret" until such time as I find somebody who can help me get a
patent on it.

> >and finally to include
> >the above algorithm for distinguishing possibly-useful moves (YES
> >per the above spec) from moves that are obviously worthless or
> >actually bad (NO per the above spec),

> How about a proof?

Huh? How can I prove that a move is "obviously worthless or
actually bad" if it satisfies my criterion?? It seems we have to
first define our terms and *then* we can make a claim using those
terms. All I have is a set of restrictions on legal moves, and a
claim that random lookahead of moves respecting those restrictions
will always terminate, and prior to terminating it'll never kill a
solidly connected two-eyed group and never break a minimal-liberty
seki (but it might kill a two-eyed group that isn't yet solidly
connected, and might break a seki if there are any extra
liberties). Is that the theorem you want me to prove, or what?

> >Experiments
> >late that night into Monday morning showed that in EVERY case the
> >algorithm reached a stable state, never self-destructing a group
> >that was absolutely alive (two eyes) and never breaking a seki,
> >always stopping when all eyes have been reduced to one-point eyes
> >and all sekis have been reduced to minimal liberties.
> Experiments are good - proof is better:)

There was an article in the American Mathematical Monthly several
decades ago equating a FOR-ALL/THERE-EXISTS statement in logic with
a two-person zero-sum all-or-nothing game. The thesis was that
sometimes it's better to just challenge crowdsourcing (using
21st-century jargon instead what the AMM used long ago to make it
more succinct) to see who wins a game rather than write a formal
proof as to who wins. Besides, checking a proof to see if it's
correct begs the question back to crowdsourcing of referees for the
proof, or else gets into infinite regress proving that the proof is
correct, or else requires conversion of the formal proof into
something that can be fed into an automated theorem-proving
program, but then who proves that the automated theorem-proving
program doesn't have a bug that mistakenly accepts a false proof?

Also, I can't define my algorithm with mathematical precision until
after I get a patent on my true/false-one-point-eye algorithm so
that that part of the algorithm can safely be made public, and
without defining my algorithm so precisely there's nothing to prove
that can be precisely stated.

> >Furthermore, if you are playing against the computer, if you pass
> >before the above critera have been satisfied, my algorithm will
> >give the computer the ability to continue to make additional moves
> >which might steal some points from you (killing some of your live
> >stones or rescuing some of its own stones) if you fail to respond
> >correctly, as well as make safety plays for its own groups, as well
> >as take dame if any are unfilled (you should have taken them
> >*before* you passed, you definitely lose points in this case if
> >there are an odd number of dame or if you fail to match the
> >computer at filling half the dame each), until the above criteria
> >are finally satisfied, at which point it will be able to count the
> >score.
> Ok.

Furthermore I imagine a Go server (using area scoring from the
outset, or during second stage of Lasker-Maas) whereby after a
player passes, if the opponent next also passes, the game-finisher
in the server will not tell the first passer that there was another
pass, but instead will pretend to be the other player, playing
additional moves against the player who passed first, and whenever
any of those moves threatens already-settled life/death questions
the first passer will be forced to stop passing or else suffer loss
of his group or life of dead opponent's group.

Likewise after two passes, the second passer will be confronted
with the computer playing moves on behalf of the first passer.

If either player makes a mistake and lets the computer steal
points, two different scores are computed, one for each player
against the computer, and if it turns out that one of the two
players made sufficient mistake to go behind in points when
formerly ahead, then at this point both players are losing to the
computer, and both are marked as having lost the game.

> >If any Internet Go server were to switch to Lasker-Maas rules,
> >instead of having players manually mark dead groups (as currently
> >done on IGS, which can cause nasty disputes if somebody marks a
> >live group as dead, and in any case it's a burden on the players),
> >then my algorithm could be used during stage 2 to (1) ask players
> >to please fill dame and fill connection points etc. to satisfy the
> >above criterion, actually telling the player which groups are in
> >danger of being captured if the opponent gets unlimited sequential
> >moves, then (2) automatically remove exactly the dead stones
> >without any possible mistake/dispute.

> Good idea. Wouldn't it be straightforward to adopt your algorithm
> to other, area scoring rulesets?

Yes. Any ruleset where there's no penalty for filling your own
territory, but there is possible penalty for leaving unfilled dame
before passing (if the other player then takes advantage to fill
dame instead), which includes stage 2 of Lasker Maas ruleset, and
whole game of regular area-scoring rulesets, could use my
algorithm.

However if there's a rule that white must make the last move, with
pass stones if white would normally pass first instead, in order
that area scoring has the same result as territory-only scoring,
there might be a problem. I have never played with AGA or NZ or
similar ruleset, and haven't studied all such rulesets, so I don't
know whether random-symmetric play would give the correct result in
all cases. But I suspect that the pass-stone rule or whatever they
use would invalidate the score per my algorithm. But really I don't
know.

Note that at present I'm using only the simplified ruleset (which I
invented circa 1964 when I first thought of programming a computer
to play Go, and which I actually implemented circa 1977 on a
computer at M.I.T., whereby my "expert system" would *always* win
if given first move on 5*5 or 7*7 board, thanks to a halfway decent
heuristic for choosing semi-safe moves, plus an exception list for
exact boards early in the game; although I called it "Computer
scoring" before I learned the "area scoring" jargon during the
1990's and before I discovered the online ruleset listing which
called it "Simplified rules" or somesuch).

I plan to stick with the "computer rules" a.k.a. simplified
area-scoring rules in the near future, until I have used the Monte
Carlo algorithm to guide a higher-level algorithm that would do
actual minmax lookahead. But if I ever get the higher-level
algorithm well enough developed, whereby it self-trains to maximize
area score, then at some point I'll want to implement Lasker-Maas
rules. My current idea is that every point in the game my program
will pretend both players suddenly pass, entering stage 2 of
Lasker-Maas rules, then the Monte Carlo lookahead will compute who
controls which points of the board, then an adjustment to the score
will be made according to who made more moves prior to this point
in order to correctly compute the empty-territory-only score. This
adjusted score, instead of the raw whole-area-score, would guide
the minmax optimization to distinguish between two possible next
moves that yield the same whole-area score but maybe one of them
gets one more point than the other under empty-territory-only
score. But until such time as it's close enough to the end of the
game that brute force lookahead can guarantee maximal area score in
a reasonable time, there's no point bothering with trying to
guarantee maximal empty-territory-only score.

Google-groups-search-key: imtrgfdi

[Robert Jasiek]

Hello Robert,

I would like to reply in greater detail, but so far do not find the
time to do so.

>> - it is surrounded by one player's stones of essential strings,
>
>Huh? This sounds like jibbeish.
>
>> - it does not contain any stone of an essential string,
>
>More apparent jibberish.

You have correctly identified the weak point: "essential string"
versus "non-essential string" is an open research question. For you,
who you are interested in a well-defined computer algorithm, at the
moment this makes usage of "essential" a no-go area. Currently, only
heuristic indentification is possible, and infrequent borderline cases
can be constructed.

[Robert Maas, http://tinyurl.com/uh3t]

> From: Robert Jasiek <jas...@snafu.de>

Ah, that's a great relief to me. When you didn't reply for weeks, I
feared that you were offended by my "jibberish" remarks about text
that you had posted and apparenty respected. I felt bad that I
couldn't understand WTF the ING-rules folks were mumbling about,
and nobody would explain it to me so that I could finally
understand. But now you have revealed the secret, that use of
"[non-]essential string" isn't something everyone else understands
except stupid me, rather it's exactly the "hand wave" or "beg the
question" as I always suspected. To point, it's not a definition at
all, it's a theme for eventual definition, rather like "string
theory" seems to be currently. Thanks for replying and explaining
why you haven't fully replied yet and letting me know I'm not
stupid and you don't think I am, at least not on this point.

I actually came back to this thread to whine that nobody has shown
any interest in my current Go-game programming in weeks, so I won't
bother to post anything that nobody wants to read, about my more
recent progress since I previously posted. But also I came on to
confess that I made one mistake in my definition of whether a legal
move is "permitted" or not for purpose of generating all possible
outcomes from a given starting position, and thus generating
worst-case bounds on how the score will end, and if the worst-case
is a single point then declare the game score is already completely
determined. My definition prevented breaking sekis, except where
sacrifice of dead-shape (up to rabbity-six) would result in the
surviving group having only one eye thus dying in the end. It also
allowed throw-in of dead-shape within a large eye. But just a day
ago I discovered a case that it was handling wrong: Self-atari at
cutting point, the eye-stealing throw-in tesuji. My algorithm never
made such moves, thus failed to include scores that could result if
such moves would be made. And of course if the
random-permitted-move algorithm were actually playing one color in
a game, it'd never play that tesuji, and thus miss chances to win
the game. After much thought, late Tuesday I finally figured out
how to include cutting-point throw-ins, and have most of the key
code written, have tested that new function on several examples.
Now I just need to fit this one function into the toplevel
permitted-or-not function, and then see if it gives correct results
in practice.

Here are a few troublesome examples, where new function fixes the problem:

A B C D E F G

7 - X X X O - - 7
6 X - X O O O O 6
5 X X O - O - X 5
4 O O O - O O - 4
3 - O X O X O O 3
2 X - X - X X X 2
1 - X - - - - O 1

A B C D E F G

bD5 is bad self-atari, not permitted, because white captures it to
make an eye, and my program got that correct already.

bD4 was also rejected as bad self-atari, but my new algorithm
recognizes it as a throw-in eye-stealing move, which is
*permitted*.

bF7/G7/F5/G4 wF1/C1 are all bad self-atari, not permitted, no change needed.

Note that some moves such as breaking seki without dead-eye-shape
absolutely must be avoided, some moves such as filling large eye
with dead-eye-shape absolutely must be permitted lest you fail to
kill a one-eyed group, while other moves don't make any difference
whether permitted or not, such as sacrificing stones at F7 or G8 in
opponent's eye, you don't lose points (under area scoring), but you
do lose a tempo (sente) by making such a dumb move before the score
is determined. For those don't care moves, whatever is a
side-effect of one of the algorithms that result from the
absolutely-permitted or absolutely-to-avoid constraints, is fine
with me.

A B C D E

5 O O - X - 5
4 O - O X X 4
3 - O O X - 3
2 O - O X X 2
1 O O - - O 1

A B C D E

wD1 was mistakenly treated as bad self-atari, hence not permitted,
but my new algorithm correctly treats it as eye-stealing throw-in
tesuji. Next, black captures at C1, then white re-takes at D1, and
now black can't turn E1 into an eye. If white misses that tesuji,
bD1(1) makes an eye. In this situation black already has two eyes,
but if black had only one other eye then wD1 etc. would kill black,
while bD1(1) would make a second eye. Even with black already
having two eyes, three points of area-counting score can go either
way depending on subsequent moves:
wD1 wC1 (all 3 for w)
wD1 bC1(2) wD1(1) bE1 wC1 (2 for w, 1 for b)
bD1(1) wC1 (1 for w, 2 for b)
bD1(1) bC1 (all 3 for b)

Note if black was stupid enough to play C1 first, then wD1 would
have been permitted by the original algorithm, because captures are
*always* permitted in random-symmetric play-to-end. Only moves that
*obviously* reduce an unconditionally live group to death, or
*obviously* break a seki to death which gives two eyes to enemy
group, thus actually lose points compared to not playing them, are
*required* to be not permitted. Only moves that have the potential
to gain points compared to letting the enemy have your point
instead, are *required* to be permitted. All other moves can be
permitted or not, whatever makes the algorithm simplest.

Note that with Monte Carlo play-to-end, multiple such paths to end,
generating a distribution of possible final scores, some individual
moves that are chosen will actually lose points compared to other
points, but it wasn't *obvious* they'd lose points, so they were
permitted. Sometimes one player will lose points because a random
sequence has him shooting himself in the foot in some non-obvious
way. Other times he loses points because the other player randomly
got several moves in a row and made good use of them to steal
points from the first player. But the more Monte Carlo samples you
run, and the closer you get to the end of the game, the better the
resultant distribution of likely final scores matches what could
really happen between skilled but not perfect players.

After I patch this new algorithm into the main permitted-or-not
function, and run some more tests on my current build-game-tree
rig, when things look stable and correct, no more flaws in my
algorithms, I'll write up what I've accomplished, with good
examples, on a Web page, and post the URL here, now that I know
that at least one person is interested in my progress. Then I'll
set up a Web-accessible live play-against-human service to see if
any of you can discover a remaining flaw in the algorithm. In
addition to presenting positions it knows about, I'll provide a way
you can upload a game from IGS where both players passed, and my
server will pretend we're using Lasker-Maas rules, and will thus
suggest what moves should be made next during stage 2 of the game
to solidly connect tactically-live groups into absolutely-living
groups, after which it'll display what's alive and what's dead, and
then compute and display the score, then if you want it will
suggest the most efficient way to capture dead stones. If you
believe any stones it says are dead are really alive, or vice
versa, you can play against the computer to try to upset the
computer's prediction of which stones are alive/dead.

Google-groups-search-key: imtrgfdi

[Robert Jasiek]

Robert Maas, http://tinyurl.com/uh3t wrote:

>couldn't understand WTF the ING-rules folks were mumbling about,
>and nobody would explain it to me so that I could finally
>understand. But now you have revealed the secret,

Not quite:) Explaining "ko" was the most difficult task. But to get a
full understanding of Ing Rules, one would also need to define their
superfluous terms:)

>letting me know I'm not stupid

Uh, certainly not! I recall the 90s when we had different opinions on
finer grain terminology, but having different opinions is not
stupidity - rather it is a good basis for finding new insights!:)

>discovered a case that it was handling wrong: Self-atari at
>cutting point, the eye-stealing throw-in tesuji.

The way to avoid overlooked cases is to list all known cases, then
prove that the case list is complete. If one cannot prove, then it
might be too difficult or an indication of incompleteness.

> [Nice new discoveries skipped]

> A B C D E
> 5 O O - X - 5
> 4 O - O X X 4
> 3 - O O X - 3
> 2 O - O X X 2
> 1 O O - - O 1
> A B C D E

>[...]

>Note if black was stupid enough to play C1 first,

C1 can be a time-suji (but this is not your concern).

>it wasn't *obvious*

For your purposes, what distinguishes obvious from not obvious?

>After I patch this new algorithm into the main permitted-or-not
>function, and run some more tests on my current build-game-tree
>rig, when things look stable and correct, no more flaws in my
>algorithms, I'll write up what I've accomplished, with good
>examples, on a Web page, and post the URL here,

Great!

>now that I know that at least one person is interested in my progress.

I am reading a few books on science history: great discoveries
overlooked for decades and partly even lost entirely were almost the
norm;) Research results are created for eternity - not just for a
lifetime!

>Then I'll
>set up a Web-accessible live play-against-human service to see if
>any of you can discover a remaining flaw in the algorithm.

If possible, please avoid security-risky Java applets!

>can upload a game from IGS

Not SGF in general?

[Robert Maas, http://tinyurl.com/uh3t]

RJ>>> You have correctly identified the weak point: "essential string"
RJ>>> versus "non-essential string" is an open research question. ...

REM>>couldn't understand WTF the ING-rules folks were mumbling about,
REM>>and nobody would explain it to me so that I could finally
REM>>understand. But now you have revealed the secret,

> From: Robert Jasiek <jas...@snafu.de>
> Date: Wed, 26 Dec 2012 15:50:33 +0100
Oops, I downloaded your article and had it sitting in my
NNTP-to-reply file but got busy with other tasks and haven't
started composing my reply until Apr.15.

> Not quite:) Explaining "ko" was the most difficult task. But to get a
> full understanding of Ing Rules, one would also need to define their
> superfluous terms:)

Well, what I meant by the "secret" was that their so-called rules
aren't really rules as such, they are merely topics for future
research. The secret is that there's a flim-flam man behind the
curtain, rather than a magnificant Oz before you, so it's fine for
me to ignore the ramblings of that flim-flam man who wrote the
"rules" for Ing Go.

REM>> letting me know I'm not stupid

> Uh, certainly not! I recall the 90s when we had different opinions on
> finer grain terminology, but having different opinions is not
> stupidity - rather it is a good basis for finding new insights!:)

Ah, (belated) thanks for clearing that up.

REM>> discovered a case that it was handling wrong: Self-atari at
REM>> cutting point, the eye-stealing throw-in tesuji.

> The way to avoid overlooked cases is to list all known cases, then
> prove that the case list is complete. If one cannot prove, then it
> might be too difficult or an indication of incompleteness.

Proving that a list of cases of types of moves, distinguished between:
- Those which must NOT be made, because they trash the position that
has been achieved up to that point (putting the life of an
absolutely-alive group back into question, or breaking a seki so
that the opponent can now capture your group);
- Those which MUST be made before the score can be auto-counted,
because without those moves made there will be unfilled dame
(which are unresolved points under area-counting rules) or
not-yet-killed dead groups (which screw up auto-counting
totally);
- Those which can be played or not, doesn't matter for purpose of
auto-score, because other moves that MUST be made will render
them moot whether played or not;
is in fact an exact partition of all legal moves, is not trivial,
and then proving such an exact partition in fact is CORRECT per the
NOT-make/MUST-make conditions in the first two clauses above, is
also not trivial. Perhaps "trivial" should read "feasible" in one
or both clauses of that just-previous sentence-tail. But even
moreso, it's not possible to PROVE something (mathematically I
presume you mean) until first a set of rigorous definitions are
provided, and also a set of axioms are provided, such that the
theorem then follows logically.

Ideally the conclusion desired should be that the "right" result is
achieved by playing forward to an automatic stopping point (no
further legal moves exist except those within the must-NOT set),
but it's a matter of personal opinion what the "right" result
should be, so that's not a feasible goal for a mathematical proof.

Alternately, the theorem should simply be that the forward-play
always terminates, nevermind whether anybody considers the result
"right", but that would seem too trivial to satisfy by an absurd
partition of moves.

I find it hard to find any goal (final line of PROOF) that is
nicely between those extremes, so trying to PROVE any result here
seems unreasonable. Also, even if we could establish a reasonable
goal, and write a PROOF that we indeed reach that goal, I see no
way to verify that the PROOF is correct, except by asking Go
theoreticalists such as you to check the proof, which takes us
right back into opinion rather than mathematical fact. Accordingly
I would, for the continuing present anyway, prefer to evade
pressure to prove anything, and instead resort to show-and-tell,
i.e. I give some examples of boards that weren't yet auto-countable
as they stood, but where humans generally agreed to the "correct"
score, where application of my symmetric-random play-to-end
algorithm resulted in the same auto-counted score on multiple
Monte-Carlo tries, which agreed with the humans-agreed "correct"
score. Then eventually I set up a Web-server application, whereby
anyone (except a 'bot) can submit a board, and the application will
play to end a few times and show the final boards and corresponding
scores (and optionally the actual sequence of random-symmetric
moves that advance from the submitted board to the final board),
and will then summarize as to whether the final score is unique or
not. (Or maybe show the unique-score-or-range at the top and leave
the details for later, i.e. "bottom line" at the top as a
"headline".)

REM> A B C D E
REM> 5 O O - X - 5
REM> 4 O - O X X 4
REM> 3 - O O X - 3
REM> 2 O - O X X 2
REM> 1 O O - - O 1
REM> A B C D E
REM>[...]
REM>Note if black was stupid enough to play C1 first,
(then the final-score-range is nudged toward white's favor,
showing that bC1 is a bad move compared to bD1 which is the best move)
(reminder: always using area-scoring)

> C1 can be a time-suji (but this is not your concern).

I understand "time-suji" as used here means a move that loses some
points compared to the best move, in return for not immediately
running out the clock and thus forfeiting the game? In other
contexts, a "time-suji" doesn't directly lose points, it merely
wastes a ko threat, which may or may not affect the score depending
on whether a suitable ko turns up later. Are we in agreement?

REM>it wasn't *obvious*

> For your purposes, what distinguishes obvious from not obvious?

Well in that context, I was trying to devise a rule for permitted
moves for purpose of random-symmetric play-to-end, and at my
original level of understanding I hadn't thought of some particular
difficulties yet, and later they bit me, and I learned from
experience, and adjusted my permitted-move rule to fix the problem.
So "obvious" means things I immediately considered at the start of
this research project, while non-obvious means things I failed to
consider initially which later bit me and thus required changes to
my permitted-move rule.

REM>After I patch this new algorithm into the main permitted-or-not
REM>function, and run some more tests on my current build-game-tree
REM>rig, when things look stable and correct, no more flaws in my
REM>algorithms, I'll write up what I've accomplished, with good
REM>examples, on a Web page, and post the URL here,

> Great!

Um, maybe great if I ever get around to it! I got sidetracked by
other things that were more urgent, as well as bogged down by one
part of this research task taking a lot longer than expected,
forcing me to eventually abandon it so that I could work on more
urgent tasks unrelated to Go.

The bog-down experiment was to start with a particular board
position which was *not* finished, and where in fact one of the
players had made a mistake, which would permit the other player to
make a cut (where no cut was tactically possible before the
mistake) and thus gain advantage, capturing some cut-off stones
that would have been alive-to-end before the mistake was made. The
experiment was to see whether my program, playing only against
itself, no human input, building a game-tree and augmenting it with
each re-play against self, using the Monte-Carlo samples at each
ply to choose which line of play to explore each time the game is
replayed, whether that would eventually discover the now-possible
cut, and furthermore would preferably choose that cut because it
really does move the final-score in favor of the player who made
the cut. Unfortunately the Monte-Carlo algorithm I was using, even
after making it better and better, still converged so very slowly
toward the good-cut and followup-to-cut that I got emotionally
burned out, and when the Unix host was re-started, losing the
game-tree built up to that point, I never found time to get back to
running it again to re-build the game-tree, and in fact never found
a good time to get back into this research project at all. Although
you have encouraged me to PROVE my results, saying my research
would be interesting to you IF I can PROVE something, you haven't
exactly encouraged me to proceed without a formal PROOF, and one
other person who expressed slight interest last year has shown no
further interest lately, and not one other person has shown ANY
interest whatsoever, so overall it looks like not one person will
care if I get back to this project or not, so emotionally I have no
social incentive for it, so it remains on back burner, not
re-started since December.

(Side: My current active project is a new kind of online
matchmaking system that rates photos honestly, and rates text
separately from photos, and requires RLlink verification of each
user before that user is allowed to meet anyone. That kind of Web
service seems more in social demand than a Go-scoring demo.)

> I am reading a few books on science history: great discoveries
> overlooked for decades and partly even lost entirely were almost the
> norm;) Research results are created for eternity - not just for a
> lifetime!

Dry PROOFs sometimes last many generations (or even "forever" as
best we can estimate so-far), such as Euclids theorems for geometry
which are still taught in high school, and still used as examples
of beautiful theorems, but more often it's only use of such
theorems in further work that survives, and any theorem not
subsequently used tends to be forgotten. Accordingly it seems
better for me to develop something of practical value that will be
adopted by various online Go servers, and eventually become the
norm on such servers, the way JPEGs have become the norm for
downloading images, the way the Floyd-Steinberg "error diffusion"
algorithm has become the standard for dithering, the way the
treble+bass clef notation has become the standard for publishing
musical scores, the way the Turing machine has become the standard
for defining general-purpose computing machines, etc. If my name is
remembered half as well as Turing, because I've created a lasting
standard, and the algorithm I created is used as productively as
Turing's machine is, that would be nice.

(Side: Some *other* great projects I've been working on are
actually perferred by me for posterity. If my plan to end
unemployment worldwide and thus end dire poverty worldwide and thus
greatly reduce the need people have to resort to crime war and
terrorism just to survive, results in getting me the Nobel peace
prize, that would be rather nice too, probably better than getting
my Go-game-auto-scoring algorithm adopted, apologies to Go fans.)

REM>Then I'll
REM>set up a Web-accessible live play-against-human service to see if
REM>any of you can discover a remaining flaw in the algorithm.

> If possible, please avoid security-risky Java applets!

I abandoned Java applets back around 2005 shortly after I first
tried them, when I discovered that very few Web browsers support
them, thus Java applets hardly ever function, thus making work on
them a waste. JavaScript is much more commonly available, even
though it's an awful malware-risk too. And JavaScript has the
ability to make calls to Java classes, so Java applets seem
unnecessary anyway. But then calling Java from JavaScript might
suffer the same security risks as Java applets. Do you know the
fact of that?

REM>can upload a game from IGS

> Not SGF in general?

I haven't discovered a way to display the current game position in
SGF while observing a game on IGS, so I haven't bothered to try to
learn the formal spec of SGF yet. (And per chicken-and-egg
situation, I haven't yet tried to find out how to display the
current board in SGF. Without a way to display in SGF, I have no
urgency to write or find a parser for it, and without a parser I
have no practical use for displaying the game in SGF.) Scraping the
verbose-mode board-position seems easier than dealing with SGF,
sigh.

Google-groups-search-key: imtrgfdi