Re: [gnugo-devel] two stone games

[bump]

> the bad thing is that break-in code indeed seems to be quite useless
> in at least games against 3.2.

It's also rather hard to make sense of what it's doing. I don't think
that Arend's comments are enough explanation.

If you load the game break_in.sgf with the option -d0x102000 you get a bunch
of traces. Among them, you find (for example):

Trying to break in from E7 to:
B9 (1)  C9 (1)  B8 (1)  C8 (1)  B7 (1)  C7 (1)

OK, so you load the file in gtp mode and enter the commands:

start_sgftrace
break_in E7 B9 C9 B8 C8 B7 C7
finish_sgftrace vars.sgf

The file vars.sgf will now contain some variations one call to
break_in. You will see that a lot of strange moves are considered,
but that is not necessarily bad. The tactical reading code
considers a lot of stupid moves, always finds the right one, and
it is very fast.

But it's hard from experiments like this to really understand
what is happening in this example.

The new move found by the breakin code in this file is G7 by
black, which is a nice tesuji. The move is a sacrifice which
is captured by W:G8. But after B:G7 W:G8 black has the atari
at G5 and white is cut. That is how I understand this
move. How does the breakin code understand it?

If you load the same file with -d0x800 you see that B:G7 gets
cut/connect strategic value but how this gets done from the
breakin code is not yet clear to me.

On the regressions the time penalty of the breakin code seems
to be about 10%. In games it seems to be more than 25%. I think
if this expensive code is to be enabled by default we need to 
understand it.

Dan