Re: [gnugo-devel] gnugo 3.4 problems

[bump]

I wrote:

> A proper solution to this might require expanding
> the data bits in struct Hashnode (see cache.h). A
> comment there suggests that this is not too bad.

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.

> If we can find two bits somewhere in the Hashnode our
> existing KO_A and KO_B could be arranged in a hierarchy
> of eight possibilities, from best to worst:
> 
>        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

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.

Dan