[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] blunder:36 fails

From: Gunnar Farnebäck
Subject: Re: [gnugo-devel] blunder:36 fails
Date: Fri, 28 Dec 2007 18:52:31 +0100
User-agent: Mozilla-Thunderbird (X11/20071008)

Terry McIntyre wrote:
> I just checked out the CVS and compiled it, using
> cvs -z3 -d:pserver:address@hidden:/sources/gnugo co gnugo
> Would this include the latest modifications, Gunnar?


> In any case, I ran regress.pike, and got an unexpected failure:
> address@hidden:~/gnugo/regression$ ./regress.pike blunder
> blunder:36      FAIL H5 [J4|H3|J3|H2|J2]
> blunder                                 11.54   3958409    4165    18107
> Total nodes: 3958409 4165 18107
> Total time: 11.54 (11.55)
> Total uncertainty: 4.19
> 1 FAIL

This is expected(!). The blunder:36 test was added on December 3 and
the convention is to set new tests as expected to pass, which if
incorrect is updated at the next release (occasionally at other
times too).

> blunder:36 is:
> loadsgf games/blunder25.sgf
> 36 restricted_genmove white H5 J4 H3 J3 H2 J2
> #? [J4|H3|J3|H2|J2]
> Saved the game after white played H5, and ran gnugo -t --decide-dragon
> H5 on that game:
> address@hidden:~/gnugo/regression$ ../interface/gnugo -t
> --decide-dragon H5 blunder25_H5.sgf
> finished examine_position
> owl_attack H5
> Pattern VA9 found at H3 with value 45
> Variation 0: ALIVE (2 or more secure eyes)
> H5 cannot be attacked (1 variations)
> owl_defend H5
> Pattern VA9 found at H3 with value 45
> Variation 0: ALIVE (2 or more secure eyes)
> H5 is alive as it stands
> This is incorrect. Gnugo 3.7.10 has the same error, as does a cvs
> version from a few days back.
> Once black plays H3, gnugo correctly recognizes that the dragon is
> dead, and resigns shortly after.

This was a bit worse than expected and is due to a connection
intransitivity. G3 can be cut off from H4 (with H3 of course) but H4
can't be cut from K4 and K4 can't be cut from G3. The dragon
amalgamation fails to handle this and then there's not much for the
owl code to do.

If you have missed it this position was also discussed in


reply via email to

[Prev in Thread] Current Thread [Next in Thread]