Problem with tactical defenses in do_owl_defend()

[nando]

The starting position (from trevorc:940)

The context is the OWL attack of E2. In some variation (W:G1 B:E3 W:E4 B:F1 W:F3), the reading gets to this position:

at which point current CVS only tries B:G1 and fails to find a defense. Note: the goal at this point is composed of 3 stones, the E3 string and the F1 ko stone.

In one of my current experiments though, the OWL code does find B:D1 as a "tactical_defense" and I had a hard time figuring out why there was a difference.

Starting at line 2578 of owl.c, there's a piece of code which looks strange to me. The problem is that the owl->goal array is filled with 1's and 2's. And I believe that occasionally, empty intersections where there was a or some goal stones (which got captured) may also still be marked in the goal array.

Is this a bug or a feature ? What was exactly intended here ? I would change for

	    goalcount += (owl->goal[k] > 0 && board[k] == color);

but I could be missing something (wouldn't be the first time)

[arend]

Yes, this looks like a bug. The wrong assumption that owl->goal cannot be non-zero for empty intersection has occasionally lead to bugs.

The goalcount heuristic looks crude to me anyway, but we should definitely try out your bugfix.

[nando]

I got around testing it, here the results.

First, a (logical and expected) performance penalty.

Total nodes: 1652879005 3267230 11890449 (+0.3 +0.9 +0.1)

Second, a breakage composed of 2 PASSes and 7 FAILures.

• trevorb:960 FAIL D5 [!D5]

After W:D5 B:C3 W:E4 B:E5, the OWL code now finds W:F4, which makes the white string much harder to catch for the engine. The attacking side of the OWL code also fails to find B:E7 after W:D5 B:C3 W:E4 B:F3 W:E6 (was already so in CVS). In conclusion, the defense was improved, the attack wasn't.

• manyfaces:7 FAIL H3 [R2|S7]

F3 becomes critical, shifting GNU Go's attention to another poart of the board. The OWL code now finds a tactical defense (W:D3) after W:G2 B:H3 W:E3 B:F2 W:E4 B:F5. Considering the aji at H2, I think that OWL should consider playing there first in that variation in order to secure the lower stones, but it seems that it can't find that move.

• nngs:120 FAIL Q4 [!R5|Q4]

OWL reading was already quite wrong, and it gets even worse, but it's not really the fault of the patch. A possible solution could be to add a 'b' attribute to pattern D1353 (or to split the pattern depending on whether the defending stones can be disconnected or not)

• trevorc:940 FAIL D2 [G1]

As mentioned earlier, the OWL reading is actually improved.

• 13x13:37 PASS E10 [E10]

Looks good to me. D9 isn't seen as critical any longer (I'd agree that it's at least quite hard to kill), what generates a large (and positive) change in move valuations all around the board.

• owl1:333 FAIL 1 B17 [0]

Accidental. The test passes as soon as owl nodes are increased to 1020.

• manyfaces1:60 FAIL R3 [N18|G18]
• manyfaces1:70 FAIL R3 [M10|L9|L8|K7]

Too many pointless attack moves in response to new attempts to defend R4. Not the fault of the patch, in my opinion.

• 9x9:290 PASS F5 [F5]

Looks good. The OWL code isn't convinced anymore that F4 kills G4.

I'm not sure what to think about it. The patch looks logical and seems to actually improve some readings. But the improvement is asymetrical, and this leads to problems (not to mention the performance penalty)