Re: [gnugo-devel] Evan's tests

[Evan Berggren Daniel]

Thanks for the comments.  I'll make changes tomorrow.  By way of
explanation, I've put up the matchercheck results on the web, which should
point out what's going wrong.  In some cases I can't tell exactly what's
going on, so I put something in that I thought was close.  I don't have
the nngs matcher_check results, so I'll rerun those tomorrow.

Also, I noticed the | used... but sometimes, I get GTP output back with
multiple answers, in which case [1 A|B] wouldn't match "2 A B".  What is
the policy for this?  use | and not worry about it?

Thanks again

Evan Daniel

On Mon, 9 Sep 2002 address@hidden wrote:

>
> Here are comments on some tests recently submitted by Evan.
> Many of these positions are very complex. Evan may not be
> aware of the use of | when alternate solutions are correct.
> Some of the tests I don't understand and maybe Evan can give
> more explanation.
>
> (I) These are comments on Evan's 9x9 tests. The tests not
> commented on seem valid.
>
> Test 1: J2 does not owl attack J3, since if B answers
> by connecting at J4 it is hard to see how W is going
> to kill.
>
> Test 3: F3 does not owl attack E3. If W defends normally at
> F2 then C2 and H3 are miai and I'm reasonably sure that W is
> alive. On the next move, however, W plays a bizarre defense
> at E1, and --decide-dragon shows that W does not know how to
> defend correctly. The real test is therefore at move 19.
>
> (II) Comments on Evan's revision of the NNGS auto tests.
>
> Test 7: this is difficult because it is a semeai problem.
> P2 may work but it is certainly not the only move here. I
> would play W J4 in this position to deprive B of an eye, and
> L2, M2, perhaps even O2 may work. Since there are
> alternative solutions, they must be given. But I don't think
> this is really a good owl test, though it could be rewritten
> as a semeai problem.
>
> Test 9: I don't disagree with Evan's comment but about the
> J7/J8 semeai. But also J4 would put W one move ahead. L10
> is probably a better move, but giving it as the unique
> answer to this owl defense test is wrong.
>
> Test 11: As already explained L10 is not the unique
> answer. L2 seems inferior to J4 because if B takes
> J4 he gets 7 liberties. If W takes J4 B has effectively
> only 4. Evan says "not sure how to look for both."
> Use | (See owl.tst for examples.)
>
> Test 12: I don't understand this test. Apparently Evan has
> confirmed that GNU Go incorrectly believes that F9 connects
> the stones at H10 and F7. The function owl_connection_defends,
> which is called by the test, resides in owl.c and has the
> following description:
>
> /* Use the owl code to determine whether connecting the two dragons
>  * (target1) and (target2) by playing at (move) results in a living
>  * dragon. Should be called only when stackp==0.
>
> It seems to me that calling this function is therefore MEANINGLESS if
> (move) does not connect (target1) and (target2). So this test
> seems wrong to me.
>
> Test 13: This looks wrong to me. The question is whether at move
> 56, before B plays G10, H10 is critical. How can B capture it?
> The game move at G10 can be answered at H10 and is very unclear
> that B can capture it. It's also not a particularly important
> stone. Generally let's not make owl tests for singleton stones
> which are not cutting stones.
>
> The remaining tests are unnumbered. I'll assume they are
> numbered consecutively for the sake of discussion.
>
> Test 14: GNU Go certainly understands on the basis of the
> tactical code that F11 captures E10. This does not need to
> be an owl test. Run gnugo -T on this position and notice
> that the F11 stones are critical (red).
>
> Test 15: similar comment. As a general point if the tactical
> reading code understands the status of a dragon consisting
> of a single string having four liberties or less the owl
> code is not too relevant.
>
> Test 16: good test.
>
> Dan
>
>
> _______________________________________________
> gnugo-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnugo-devel
>