gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] Optics improvement


From: Gunnar Farnebäck
Subject: Re: [gnugo-devel] Optics improvement
Date: Thu, 27 Jan 2005 06:33:33 +0100
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.9) MULE/5.0 (SAKAKI)

Martin wrote:
> I have tried to make GNU Go handle eye spaces like
> 
> .....OOOOO
> .OOOO.XX.O
> .OXXXX.X.O
> .OX.OOOX.O
> ----------
> 
> better, which was previously considered unconditionally alive (in seki).

Cool. This has been a rather embarrasing weak point.

> I have extended topological_eye to set the value for a diagonal to 2.0,
> if all of the following holds:
> a) It is not 2.0 already.
> b) The diagonal is occupied by an opponent string,
> c) which is also adjacent to the (potential) eye and 
> d) at least three stones long.
> e) The (potential) eye is not on the edge (to steer clear of all the
> hairy cases that are handled by eyes.db anyway).
> f) At least two own strings are adjacent to the (potential) eye.
> g) At least one of the own strings adjacent to the (potential) eye has
> only one liberty which is an eye space and not decided false, yet.

I have a feeling that there are situations where these conditions go
wrong (i.e. don't just miss something but break something), but those
are in all likelihood more infrequent than the solved situations. I'll
see if I can come up with a few to add to the test suite for a later
generation solution to this problem.

> I am dubious about d), which seems a little arbitrary. However, it did
> help reduce OWL tries of irrelevant marginal eye spaces.

It might miss some case, but mostly it seems reasonable.

> Furthermore, I'm not to sure whether using is_proper_eye_space (for
> g) ) at this point is reasonable. Maybe someone with more intimate
> knowledge could comment on this?

No, it's not reasonable. It might make some sense when eyes are
computed in make_dragons() but when topological_eye() is called
(indirectly) from the owl code it's not appropriate to look at
properties of the eyespaces in the original position.

> lazarus:11      PASS S15 [S15]
> lazarus:12      PASS T18 [T18]
> lazarus:17      FAIL F2 [T8]
> nngs:820        PASS L9 [J13|L9]
> nngs:1160       PASS H8 [!A8]
> nngs:1190       PASS 0 [0]
> owl1:274        PASS 1 G7 [1 G4|G7|B6]
> owl1:322        PASS 0 [0]
> owl1:323        PASS 0 [0]
> owl1:362        PASS 1 M16 [1 M16]
> strategy5:284   FAIL E9 [R12|Q9]
> 
> That's 9 PASSes vs. 2 FAILs at a node counter increase between 0.25% and
> 0.45%.

Very good indeed. Much better than when I made a half-hearted attempt
to solve the problem. But I'm somewhat curious why nngs:1190 passes
but not nngs:1200 or owl1:303.

> I have not analysed the regression delta because I am a little short on
> time at the moment. As I don't know when that might change, I have
> decided to post the patch anyway before it starts gathering dust. Maybe
> it is of use as it is, or someone else might want to polish it up?

I think it would be better to use it as is than not at all, but it
wouldn't hurt with an analysis of the two failures and a fix for the
use of is_proper_eye_space().

/Gunnar




reply via email to

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