Re: [gnugo-devel] Pattern tuning and regression tests

[Daniel Bump]

Arend wrote:

> Instead, I wonder whether it might make sense to have an automatically
> maintained database that would just record for each pattern, which moves
> it suggested in (say) GNU Go's NNGS games.  Maybe it would be sufficient
> to only record those moves that actually got selected. At least for
> specializing and/or removing patterns, this would allow an easy check
> whether the pattern is really unnecessary. OTOH, newly added/generalized
> patterns could be checked after a while, whether they actually get used
> in "real life".
> 
> Has this been discussed before on this list? 

I'm not sure. I'd thought about doing something like that.
One could do a run of 100 games using twogtp and record
which patterns contributed some move, and which patterns
contributed the move that was actually played. This might
be useful information. If the database was considerably
larger than 100 games it might help find patterns that
are candidates for deletion.

Trevor wrote:

> With this disclaimer, I wonder the value of problems like 
> strategy:20, which are not totally clear cut.  Is it
> worth fretting over a situation that is unlikely to occur
> again, anyway?  Also, the original point of strategy:20 was 
> !R11, not so much Q11.  Had GNU Go played C11 originally, I
> doubt it would have made the regressions.

Strategy 20 looks pretty clear cut to me. After B connects
at Q11 W's four stones on the top right are baseless and
the stone at Q10 looks wasted. If W gets Q11 first, the
position is totally altered.

And, it's a very typical GNU Go bad tenuki. We see
moves in every game in which GNU Go doesn't finish
what it starts and ends up worse off than if the
local area were left unplayed to start with.

Arend wrote:

> I think Trevor mentioned this only once, you can easily go there manually:
> http://www.public32.com/regress/?strategy:37 etc.

I didn't know this! That is very helpful.

Dan