Re: [gnugo-devel] gnugo 3.4 problems

[Gunnar Farnebäck]

Dan wrote:
> W gets the ko by answering C19 with W:A14. And it isn't
> a very good ko. W has to win it multiple times and if B
> can't fight it, he can lose it about twice (taking
> profit elsewhere) then chicken out and the worst that
> can happen to him is seki. So W is fighting a very
> uphill ko for seki. So the test should be written:

What variations are you considering? I see one where white has to
ignore multiple ko threats to win the semeai but where black has no
option to chicken out (white might settle with seki at some point
though). In another variation I find black can chicken out for seki
but then white only needs to ignore one ko threat.

>        very indirect ko, favorable to me
>        2 move yose (approach-move) ko, favorable to me
>        1 move yose ko, favorable to me
> KO_A = direct ko, I make first ko threat
> KO_B = direct ko, you make first ko threat
>        1 move yose ko, favorable to you
>        2 move yose ko, favorable to you
>        very indirect ko, favorable to you

Yes, this may be good enough to be useful. 

> Maybe not, because the need for an elaborate
> classification is strongest in the case of semeai.
> The KO_A/KO_B scheme seems be adequate for ordinary
> owl reading, where there is only one group in
> question.

In my opinion we should change in all kinds of reading if we change.

> In GNU Go 3.4 there was a field semeai_margin_of_safety
> in the dragon2 data. The field was taken down at some
> point because the measure was never really implemented,
> but the idea was to have a parameter indicating how
> close the semeai was. I think there could be some
> scheme in which this parameter would used in connection
> with the KO_A/KO_B results to classify yose kos.

We still need to modify the general result codes if we want to use
caching in the semeai reading.

/Gunnar