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

[Gunnar Farneback]

Arend wrote:
> I don't know what solution you are thinking of, but an alternative might
> be to use the existing caching. If an open read result is found by
> a (minimally revised) get_read_result, we know that a superko violation has
> occurred. Then we could effectively disallow the move that lead to this
> situation by returning a WIN for the opponent.

No, this is not the solution on my mind; it's more similar to Trevor's
approach. I've long been aware of this possibility but had almost
forgotten about it, so thanks for reminding. In the early history of
the cache implementation this wasn't a feasible solution because there
was no functionality to purge the cache on the fly but this has been
resolved for quite some time now. There is also the complication that
this scheme would fail if people disable the caching completely, which
sometimes is needed for debugging purposes.

> This could take care of all superko violations.

Yes.

> We would have to enforce use of caching for all recursive functions,

This is a bit of a drawback.

> and add a "dummy" open read results for all caching function at all
> previous game position. This would take away only a small part of
> the memory usage of the hash table.

Are those dummies really necessary? To enforce a strict superko test
(with respect to the entire move history) during reading is much less
interesting than breaking local cycles.

However, this is complementary to an extended komaster scheme, which
could also prevent some other kinds of ko nonsense.

/Gunnar