Re: [gnugo-devel] Olympiad games

[Arend Bayer]

Gunnar Farneback wrote:

> I agree that D11 would be an acceptable attack (of the single C12
> stone that is, not when it was played in the game). But it isn't
> really all that important whether it actually does kill the stone as
> long as the outside is strengthened.
Agreed.

> > down the tree, we are only interested _whether_ we can kill/live. At
> > stackp==0, where the move found by owl will often be the move
> > played, it is very important to use the _right move_ to kill/live.
>
> This is how the owl code always has worked, although not necessarily

? The move ordering is still mostly guided by the pattern values, which
are in turn optimized to have the move with the best chance to kill
first, not the one that kills in the best possible way.

> very successfully. I think this is problematic and that it would be
> better if the owl code always was allowed to return just any move
> which is effective. Then the owl_does_attack() and owl_does_defend()
> functions can be used to test potentially more attractive moves for
> critical dragons.

But owl_does_defend/attack() are expensive, too. I see two possible
ways: Either the one you suggest, i.e. first finding out whether we can
kill, and then test with owl_does_defend/attack whether we can do even
better (Has it been tried out to only call owl_does_attack/defend if
they concern critical dragons?). The other is to immediately look for a
good way to kill first. This is mostly a question about efficiency.

> > G14 (57) probably has to be at G16, but may be hard to see without
> > lookahead.
>
> I assume you mean K14 (57) here. Is the intention of G16 to sacrifice
> H15 in order to get D17 in return?

Yes. One could also play at F17 directly. It is a difficult position,
and I might be wrong, but I think that after W58 at G16, the black group
at C15 can be killed. Hence capturing D17 looks more important than
starting to run away with H15 at this point.

> > B8 (69) looses a lot of points. The strategic (over-)valuation of B8
> > is bogus, whereas Q16 is enormously undervalued here (is 16.5; 30 looks
> > closer to the truth).
>
> Q16 is occupied. Do you mean Q17? If so, with the plan to then block
> at R16 or to let white live in the corner?

Yes, Q17. Then black could take outside strength with P18,
probably still end in sente and then attack the K13 group. But whatever
black does (even if he wants to tenuki as soon as possible), he should
start with the Q17-Q18 exchange.

> I didn't find S13 sufficient to live (at least not without resorting
> to semeai after a P14/O13 cut), but maybe I didn't read carefully
> enough.
I wasn't careful here. I think black can save Q14 by playing S13, but
has to give up the L15 group.

> > The second game against Go4++ (game2-19-gnugo-go4-0-1.sgf) looks
> > encouragingly close. If GNU Go would close its territory at move 80
> > (or resits at H7 with move 86), it might be leading.
>
> I imagine move 80 (or 82) could be fixed with some influence tuning.
> Missing H7 looked like a serious mistake.

While missing H7 (at move 86) has serious consequences, I don't think
it is easy to see that it works. As it stands, black can cut at G10. H7
defends against this cut. I am pretty sure your connection code would
see this, given the positions with/without H7. But we would need to
introduce frequent calls to (the not yet written function) does_connect()
to let GNU Go try this out, I suppose.

This looks very much worth doing.

> Good question. It may very well be worse at century cup, but I think
> GNU Go will be able to defend well against thrashing dragons, in
> particular after my latest patch.

Yes. Anyway, I think it is fair enough Go4++ is testing whether GNU Go
can defend against such moves, although I would never write a patch to
teach GNU Go to play such moves.

> > J4 (144) is an annoying mistake caused by a huge shape bonus (shape+10).
> > I often get the impression that such huge shape values cause a lot more
> > trouble than they help to resolve. Maybe we should review all shape
> > values bigger than +-6, or ignore the shape effect for moves with owl move
> > reasons.
>
> I wouldn't mind just eliminating all huge shape values and large fixed
> values to see what happens. I think we have better tools to properly
> solve the problems those patterns were intended for today than when
> they were introduced, if we just can find them again. Quite a few of
> them have probably been solved already by other fixes, in particular
> the influence revisions, and the corresponding patterns only have the
> effect to overcompensate now.

While I would very much like to agree, I am e.g. not so sure about this
specific shape.  I have often seen GNU Go tenuki in the following shape:

.....
..O..
..#..
.O.X.
.....

(X just played at #).
(There is an example in one of the Maastricht games, I don't remember
which one. FunGo was an expert in provoking these mistakes.)

I, too, think that this should preferably be solved by influence tuning;
but it is not easy.

Btw, I think that replacement patterns, too, could need a review like the
one you suggest.

Arend