RE: computer-go: Scoring

[Jean-Pierre Vesinet <jpvesinet@xxxxxxxxxx>]

> I think the two could fairly easily be combined.
> The first pass would be the benson absolute life/death,
> and would set the status of some of the score areas.
> The remaining contested score areas (stuff that did not
> meet the rigerous requirements of bensons') could then
> be scored using my algorithm.
> 
> I think final result would be a static scoring algorithm
> that would give better results than either of our two algorithms.

That would be nice because my method only avoids the last (terminally
stupid) moves of Tromp-Taylor. I don't think it is possible to extend static
scoring any further. All the less obvious moves require knowledge of
semeais, possible ko fights, etc. These are too difficult to be solved
statically. 

> >> a black score area is a string of [white OR empty] intersections
> > Do you mean a _maximum_ set of connected white or empty 
> intersections?
> yes.

Then I have the same, and call them regions, the more or less standard name
in the literature.

> >> two score areas can be said to intersect iff:
> > Do you mean two scoring areas of different color (one 
> black, one white)?
> two score areas of the same color cannot intersect,
> or they would be the same score area.
> So, yes.

Right. I asked to make sure we agree on the meaning. Benson has a slighly
different definition of a region involving surrounding. Each black point
belongs to exactly one white score area, (and vice versa). Each empty point
belongs to exactly one white score area and one black score area. Since each
score area has at least one empty point (or else there would be stones
without any liberty), each score area intersects at least one other score
area.

> >> 1. the status of all score areas is initially CONTESTED
> >>
> >> 2. any score area that intersects with one and only one
> >>      opposing score area has it's status set to SCORING
> >>
> >> 3. any score area that intersects with a SCORING score area
> >>      has its status set to NON-SCORING
> >
> >If A intersects B, then B intersects A, therefore SCORING score areas
> >would also need to be set to NON-SCORING ?
> 
> No.  This is because score areas have the property
> that if a score area is contained (intesects with only one
> other score area)  It will never intersect with another
> contained score area.

Then do you mean this:
3'. any score area contained within a SCORING score area
    has its status set to NON-SCORING.
Otherwise you have a circular definition with some scoring area both S and
NON-S.
For example:
6 . . . . . . . . .
5 X X X X X X X . .
4 O O O O O O X . .
3 . . . . O . O X .
2 X X X . O O O X .
1 . . X . O . O X .
  A B C D E F G
The two scoring areas in the corner intersect only each other.
With 3', the smaller would be set to NON-SCORING. Is that your intention?
If so, it seems too simple. The life and death status of the corner depends
of the shape of the score area in the corner. Here it is only two adjacent
points, and therefore it is dead (NON-SCORING?). If it were one point
bigger, it would be unsettled. Two point bigger and it would be alive
(SCORING?). How do you take shape into account?

> > > a fix, to cope with seki:
> > >
> > > any score area consisting of exactly 2 empty intersections,
> > > and at least one coloured intersection is always CONTESTED,
> > > and may not be changed by steps 2, 3 or 4.
> >
> > Too simple. Sekis can have 1 liberty in common, or 2 or 3, 
> or even more!
> > This includes the "final" state of a seki, where neither 
> player can add a
> > stone.
> Id didnt really think this one through properly.
> What is an example of a 3(or more) liberty
> seki that is in the final state?

This hane-seki has 3 liberties left: it is one of the weirdest sekis. I'm
sure there are simpler ones with more than 2 liberties. However, if you
count liberties per score area, that would be only 1 or 2. So you may be
right about 2 being a maximum - I will try to find a better example.
9 . . . . . . . . .
8 . . . . . . . . .
7 O O O O O . . . .
6 @ @ @ @ O . . . .
5 O O . @ O O . . .
4 . O @ @ @ O . . .
3 @ O @ O @ O . . .
2 @ O @ O @ O O . .
1 @ O @ O . @ O . .
  A B C D E F G H J

> Ill have to find another way around this...

There is only one method that always works: read the position (by search).
There is no static method to recognize _all_ sekis because it would mean
solving all semeais without search. That's clearly impossible. In my method,
everything stabilizes into safe stones and territory except sekis.

Regards,

Jean-Pierre Vesinet