Re: [gnugo-devel] pattern-based reading spinoffs (27.7)

[Daniel Bump]

Trevor wrote:

> Uncomment the following read_attack.db pattern:
> 
> ## This pattern can break ko-masters, but is not good for much else
> Pattern RA000ko
> 
> ?XO?  take the ko!
> X*XO
> ?XO?
> 
> :8,A,value(99)
> 
> Run with EXPERIMENTAL_READING enabled on the attached SGF file,
> and all current KOMASTER Schemes blow up.  Currently, scheme 4,
> which was designed to avoid this sort of problem, breaks too.

I note that the standard reading code does OK on this position.
The problem is after adding this pattern W seems to prefer taking
kos to filling them.

The existing komaster code starts forbidding ko captures when someone
illegally takes a ko, simulating a ko-threat/response/ko-capture.  If
there are enough kos floating around, and if both players prefer
taking a ko to filling a ko, this triggering illegal ko capture will
never happen unless we implement superko (which Gunnar might be
contemplating in view of his recent patch implementing a move stack).

But even in situations not involving ko, say a ladder or geta, the
reading code can lead to deep trees if the nodes at each branch are
not at least somewhat intelligently ordered. That's not fundamentally
different from what's happening here.

Should the aim of the komaster scheme be to absolutely limit
the size of the tree or should it be to prune it just enough
that if the players choose well then deep trees will be avoided?

BTW I'm remembering now that in the example we discussed in January
there were two kos whose locations needed to be remembered. So
just adding a bit or two to komaster didn't seem to offer a
quick solution. The preferred fix would have kept two ko points,
one for each player. I changed the ko point to the last ko taken
in a patch, but Gunnar gave reasons why that was not a complete
solution.

Dan