gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] optics / ko


From: Gunnar Farneback
Subject: Re: [gnugo-devel] optics / ko
Date: Sat, 12 Oct 2002 23:06:58 +0200
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Paul wrote:
> i tried to solve the position in Arend's mail and to get some benefits
> from improved topological eye valuations. i introduced a new optics
> layer between compute_eyes[_pessimistic]() and recognize_eye(). the
> function is called read_eye() (can anyone think of a better name?) and
> its only purpose (for now) is to solve such ko-related positions.

I think this is fine and have considered doing it myself for some
time.

> i also have some thoughts about ressurecting my eyespace/connection
> code and adding it to read_eye(). it will involve some reading (very
> same to the function does now), while i previously tried to implement
> it statically. this is a matter of future experiments, however, and
> there's no a single trace of that code in this patch.

There's reason to be careful about this reading so that the optics
performance doesn't decline too badly. Eyes are evaluated many times
per move. There's also reason to keep an eye on the code complexity so
it doesn't get out of hand.

To comment further on the optics code I think it's due for a bit of
redesign. Generally speaking the graph matching technique has been a
great success, in particular in conjunction with the owl code. Still
I believe it can do much better, in particular when it comes to
helping the owl code become more efficient.

Things that in particular need consideration:
1. All margins are considered the same by the optics code, but in
reality they can vary substantially in behavior.
2. Multiple eyespaces can interact strongly, in particular when they
are diagonally adjacent. This had better be taken care of within the
optics code.
3. It's better for the owl code to get uncertain eye estimates, i.e.
within some range, than a precise estimate which is incorrect. For the
owl performance it's important to keep the range as small as possible
though.
4. Atari inside eyespace and some other things currently handled by
owl_vital_apats.db would be better to take care of in the optics code.

/Gunnar




reply via email to

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