Re: [gnugo-devel] Tuning patch

[Gunnar Farneback]

Dan wrote:
> I've put up a tuning patch at:
> 
> http://www.gnu.org/software/gnugo/patches/tuning_3_3.1

I disagree with one of the revised patterns:
> @@ -7791,7 +7808,7 @@
>  ?*.?
>  ?OX?
>  
> -:8,OXe
> +:8,OXed
>  
>  
>  Pattern CB243

Unfortunately there's no change comment, so the start of the pattern
is missing from the diff. The full pattern is:
 
| Pattern CB242
| 
| ?..?            default if previous pattern is not feasible
| ?*.?
| ?OX?
| 
| :8,XOe

The problem is that this pattern is WAY too general for a d
classification. Although it's good in some positions where it matches,
there are much too many positions where it's absolutely ineffective as
a strategical defense. This is bad for the following two reasons:

1. A d move for a critical dragon is tested whether it works as an owl
defense by calling owl_does_defend(). This is potentially expensive
and a waste of time in contexts where the move is clearly ineffective.

2. A d move is awarded a strategical value only dependent on the
settledness of the dragon, without in any way evaluating the
effectiveness of the move. This is of course a major weakness of the
move valuation, as has been noticed several times on the list and as
FIXMEs in the code. Until we solve this problem it's important to be
very restrictive with the d classification. (There are indeed quite a
few existing d patterns already which are too general and do cause
problems. Also the same goes for a patterns.)

To sum it up I think this pattern is very likely to generate more
problems than it solves.


Another pattern being worth a comment is this one:
> +Pattern CB239
> +# db added (3.3.3)
> +# see nngs1:50
> +
> +..?       connect to reinforce and attack
> +O*O
> +?X?
> +
> +:8,OXCeda
> +
> +..?
> +a*b
> +?X?
> +
> +; !same_dragon(a,b)

To begin with the C classification is redundant. The straight
connection is already covered by the Conn101 pattern in patterns2.db.
More interesting though is that this pattern may be useful also in
cases where the O stones have been incorrectly amalgamated (because
they share an eyespace). Although this kind of problem should be
solved when the amalgamation code is reimplemented (using
readconnect), that's still in the future. What we could do now is to
replace the same_dragon constraint with a readconnect constraint, i.e.

;!xplay_connect(*,a,b)

/Gunnar