Bugfixes related to owl reading.

[gunnar]

This patch fixes three bugs related to owl reading.

1. The same_dragon function can't be used in owl pattern constraints (only valid for stackp==0) and has been replaced by same_string in A1122 and A1122a, which makes more sense anyway.
2. compute_owl_escape_values() in owl.c was assuming that it would always encounter the dragon origin before any other stone in the dragon. This is not correct since the dragon origin is placed on the largest string of the dragon.
3. get_lively_stones() in worm.c was only valid for stackp==0 but was used from owl reading where it sometimes is called at stackp==1 (e.g. in owl_does_defend()). It has been rewritten to use attack() and find_defense() instead of worm data. Thanks to caching this shouldn't make much speed difference at stackp==0.

[gunnar]

Bugfixes.

[gunnar]

Revised patch.

[gunnar]

This wasn't quite successful since the patch crashed for 13x13b:24. Fixing this in the revised patch gunnar_7_11.3b leaves regression results of

trevorb:140     PASS K2 [L2|K2]
trevor:1060     PASS 1 [1]
13x13:1         PASS M2 [M2]
13x13:17        PASS L5 [L5|L3]
strategy4:184   FAIL H16 [H13|F15|Q13]
thrash:30       FAIL D1 [J4|J7]
kgs:160         FAIL M6 [G12|H8|J7|G7]
4 PASS
3 FAIL
Total nodes: 1715431861 3344231 12899282 (+1.4% +0.23% +2.4%)

It's not clear where the big increase in connection nodes comes from but it should be checked closer.

[nando]

Replying to gunnar:

It's not clear where the big increase in connection nodes comes from but it should be checked closer.

I think it comes from the A1122(a) patterns. The change to same_string doesn't prevent the pattern from matching when both stones are in the goal, which I presume, greatly increases the hit rate and generates more calls to oplay_connect(). Beside the issue that this wouldn't actually belong anymore to the A11xx class in this form, I would suggest to try to replace the same_string() clause by something closer to what was probably meant with !same_dragon, e.g. either (!owl_goal_dragon(a) !owl_goal_dragon(b)) or (owl_escape_value(a)>0 owl_escape_value(b)>0)

[nando]

ah, those were interpreted as cell separators. I meant this:

(!owl_goal_dragon(a) || !owl_goal_dragon(b)) 

or

(owl_escape_value(a)>0 || owl_escape_value(b)>0) 

[gunnar]

Replying to nando:

Replying to gunnar:

It's not clear where the big increase in connection nodes comes from but it should be checked closer.

I think it comes from the A1122(a) patterns.

That's correct. To be more precise the pattern changes alone have the result

13x13:17        PASS L5 [L5|L3]
strategy4:184   FAIL H16 [H13|F15|Q13]
kgs:160         FAIL M6 [G12|H8|J7|G7]
1 PASS
2 FAIL
Total nodes: 1700746525 3344689 12910103 (+0.51% +0.25% +2.5%)

while the owl.c changes have barely any effect at all

Total nodes: 1692048540 3336497 12596319 (+1.2e-05% +0.00012% 0%)

and the worm.c changes give

trevorb:140     PASS K2 [L2|K2]
trevor:1060     PASS 1 [1]
13x13:1         PASS M2 [M2]
thrash:30       FAIL D1 [J4|J7]
3 PASS
1 FAIL
Total nodes: 1706823713 3335837 12593040 (+0.87% -0.02% -0.026%)

[gunnar]

Replying to nando:

ah, those were interpreted as cell separators. I meant this:

(!owl_goal_dragon(a) || !owl_goal_dragon(b)) 

or

(owl_escape_value(a)>0 || owl_escape_value(b)>0) 

It's not necessary to check both a and b since one of them anchors the pattern and is guaranteed to be in the goal.

With the revised patch

Index: patterns/owl_attackpats.db
===================================================================
--- patterns/owl_attackpats.db	(revision 2368)
+++ patterns/owl_attackpats.db	(working copy)
@@ -4372,22 +4372,24 @@
 Pattern A1122
 # tm New Pattern (3.1.22)
 #   see -l games/trevor/auto/d02.sgf -L 142 --decide-dragon P2
+# gf Revised constraint. (3.7.11)
 
 Y.
 *.
 .X
 
-:8,C,value(75)
+:8,-,value(75)
 
 a.
 *.
 .b
 
-;!same_dragon(a,b) && !oplay_connect(*,a,b)
+;!owl_goal_dragon(b) && !oplay_connect(*,a,b)
 
 
 Pattern A1122a
 # same as A1122 - different anchor.
+# gf Revised constraint. (3.7.11)
 
 X.
 *.
@@ -4399,7 +4401,7 @@
 *.
 .b
 
-;!same_dragon(a,b) && !oplay_connect(*,a,b)
+;!owl_goal_dragon(a) && !oplay_connect(*,a,b)
 
 
 Pattern A1123

the results are dramatically different:

arend:9         PASS S17 [S17]
nngs3:140       FAIL G9 [D9]
nngs3:230       FAIL L12 [!L12]
nngs3:260       FAIL G12 [G11]
nngs3:350       FAIL M5 [E12]
1 PASS
4 FAIL
Total nodes: 1690124751 3332188 12449477 (-0.11% -0.13% -1.2%)

[gunnar]

In nngs3:260 I can't see that G12 is any worse than G11. To me it rather looks better.

nngs3:230 looks like a questionable testcase.

[gunnar]

Twice revised patch

[gunnar]

The revised patch gunnar_7_11.3c has better results:

trevorb:140     PASS K2 [L2|K2]
trevor:1060     PASS 1 [1]
arend:9         PASS S17 [S17]
13x13:1         PASS M2 [M2]
nngs3:260       FAIL G12 [G11]
4 PASS
1 FAIL
Total nodes: 1708083235 3336308 12489306 (+0.85% -0.17% -0.93%)

As mentioned above G12 should be an acceptable result for nngs3:260.