Ticket #116 (closed defect: fixed)

Opened 2 years ago

Last modified 2 years ago

9x9:400 - an interesting owl failure

Reported by: gunnar Owned by: gnugo
Priority: normal Milestone: 3.7.10
Component: source Version:
Severity: normal Keywords:
Cc: patch: yes

Description

Consider testcase 9x9:400,











The problem here is that the lower left black stones are considered dead. When reading owl_defend A4, the correct move at A5 is found by pattern D1389, but then do_owl_attack quickly declares black dead in the absence of eyes. Only the three lower stones and the newly placed A5 stone are included in the goal.

Three questions arise:

  • Should the attacker be allowed to declare the opponent dead at all? Shouldn't it be up to the defender to concede defeat?
  • What is needed to get B7 and possibly other stones of the upper dragon included in the goal? Would it make sense to add a pattern classification meaning that all O stones in the pattern should be added to the goal if they aren't already?
  • Is it a better approach to try to detect this as alive by escape?

Attachments

gunnar_7_10.1.diff (21.4 kB) - added by gunnar 2 years ago.
Implementation of a classification.
gunnar_7_10.1b.diff (24.8 kB) - added by gunnar 2 years ago.
bugfixes and more a patterns
gunnar_7_10.1c.diff (25.5 kB) - added by gunnar 2 years ago.
D1345 and 9x9:400 revised

Regression Results

Attachment Rev. PASS FAIL Nodes Status
gunnar_7_10.1.diff never tested
gunnar_7_10.1b.diff never tested
gunnar_7_10.1c.diff never tested

Change History

Changed 2 years ago by arend

I think the proper solution is for owl to recognize that A5 connects out to B7.

One possible solution for this particular case is to add s.th. like a C classification to D1389, stating that the move connects all stones being part of the pattern.

However, I there will be many similar situations, and I am doubtful we would ever get a reasonably complete pattern database of moves connecting the dragon out. That's one of the reasons I started my owl escape rewrite. Unfortunately, that is pretty much stalled at the moment.

Changed 2 years ago by nando

One possible solution for this particular case is to add s.th. like
a C classification to D1389, stating that the move connects all stones
being part of the pattern.

Another approach would consist in helping the OWL code generating moves until it recognizes the connection naturally, i.e. adding a (or some) pattern(s) of the following form for instance:

O*X
..O
---

(with a proper set of constraints, of course). This would bring the position to a point where the stones are "naturally" added to the goal by means of find_superstring() in owl_update_goal().

But I agree, this all seems to lack genericity.


OT: any specific reason for making this a ticket rather than a new page under Testcases ?

Changed 2 years ago by gunnar

Another approach would consist in helping the OWL code generating moves until it recognizes the connection naturally, i.e. adding a (or some) pattern(s) of the following form for instance:

O*X
..O
---

(with a proper set of constraints, of course). This would bring the position to a point where the stones are "naturally" added to the goal by means of find_superstring() in owl_update_goal().

Yes, that would work and answers my first question. The attacker is required to ask for defense moves before declaring victory. But it's not a very good solution since it tends to waste owl nodes.

One possible solution for this particular case is to add s.th. like a C classification to D1389, stating that the move connects all stones being part of the pattern.

That was my first idea.

However, I there will be many similar situations, and I am doubtful we would ever get a reasonably complete pattern database of moves connecting the dragon out. That's one of the reasons I started my owl escape rewrite. Unfortunately, that is pretty much stalled at the moment.

Well, I think I'll implement the C classification solution while waiting for something better.

OT: any specific reason for making this a ticket rather than a new page under Testcases ?

Mostly the fact that I wanted this to be solved quickly and the required changes seemed small.

Changed 2 years ago by gunnar

Unfortunately class C means "cut possible" and although it's only used for attack patterns it doesn't seem like a very good idea to have it mean something else for defense patterns. Class c is also occupied for "combinable" patterns. So it will have to be some other random classification.

Changed 2 years ago by gunnar

Implementation of a classification.

Changed 2 years ago by gunnar

  • patch set
  • milestone changed from 3.8 to 3.7.10

This is now implemented in the attached patch gunnar_7_10.1.

Since c and C weren't free I decided to use class a, as in all, since it adds all friendly stones in the pattern to the goal.

For sanity reasons I introduced an enum same_dragon_value to replace the earlier values of 0, 1, 2 for the same_dragon flag. This should have been done much earlier.

To implement this I also had to pass around a pointer to struct matched_pattern_data in more places than is really comfortable. I expect some future rewrite will take care of cleaning up this. :-)

For now only D1389 has been given the a classification.

Testcase 9x9:400 still doesn't pass since it now prefers to play B3 instead of A5. That move looks at least acceptable to me.

Changed 2 years ago by gunnar

Very small effects on the regressions. No breakage and barely visible node changes.

Total nodes: 1683073541 3319236 12608251 (+0.0003% +0.0057% -0.0062%)

Changed 2 years ago by gunnar

bugfixes and more a patterns

Changed 2 years ago by gunnar

The revised patch gunnar_7_10.1b fixes a bug (thanks go to nando) and adds many more class a patterns to owl_defendpats.db.

New regression results are

trevorb:650     FAIL K7 [J7]
strategy4:167   PASS D4 [D4]
owl1:283        PASS 0 [0]
nngs4:170       FAIL Q5 [S6]
manyfaces1:30   PASS C14 [C14]
kgs:220         PASS T10 [T10]
kgs:320         FAIL J9 [K12]
4 PASS
3 FAIL
Total nodes: 1681713882 3310072 12580348 (-0.08% -0.27% -0.23%)

Changed 2 years ago by gunnar

trevorb:650     FAIL K7 [J7]     The D1345 constraint is too weak to support a classification (owl_attack J8).
strategy4:167   PASS D4 [D4]     Marginal improvement.
owl1:283        PASS 0 [0]       Lucky.
nngs4:170       FAIL Q5 [S6]     Not sure what's going on.
manyfaces1:30   PASS C14 [C14]   Small improvement.
kgs:220         PASS T10 [T10]   Good.
kgs:320         FAIL J9 [K12]    Unlucky.

Changed 2 years ago by gunnar

D1345 and 9x9:400 revised

Changed 2 years ago by gunnar

The second revision gunnar_7_10.1c tightens the constraint of D1345 so that a classification is warranted and adds B3 as a correct answer to 9x9:400. New regression results:

strategy4:167   PASS D4 [D4]
owl1:283        PASS 0 [0]
nngs4:170       FAIL Q5 [S6]
manyfaces1:30   PASS C14 [C14]
9x9:400         PASS B3 [A5|B3]
kgs:220         PASS T10 [T10]
kgs:320         FAIL J9 [K12]
5 PASS
2 FAIL
Total nodes: 1682140680 3309788 12591466 (-0.055% -0.28% -0.14%)

Changed 2 years ago by gunnar

  • status changed from new to closed
  • resolution set to fixed

Changed 2 years ago by alain

kgs:320         FAIL J9 [K12]    Unlucky.

in #115 this question is asked too. J9 seems safe way to victory, when K12 looks greedy but unsafe if lower right dragon is killed.

Changed 2 years ago by gunnar

in #115 this question is asked too. J9 seems safe way to victory, when K12 looks greedy but unsafe if lower right dragon is killed.

Well, for this patch the relative merits of J9 and K12 are not as interesting as the fact that the quality of the owl/semeai reading becomes worse. (An "a" pattern increases appropriately the size of the goal but then the following owl attack move cuts the newly added stones off again without the owl reading noticing and instead escapes with an irrelevant tail.)

Note: See TracTickets for help on using tickets.