Re: OpenGo Suggestion as Re: Eureka

[Dave Dyer <ddyer@xxxxxxxxxxxx>]

The cycles required to abstract the incremental change from
the previous move, or even to regerate all higher-level knowlege
from scratch, will be trivial compared to the time needed to
do even the simplest lookahead, where hundreds or thousands
of nodes will be examined. 

I support the idea that a generic "go shell" will be useful
and will prevent a lot of wheel spinning, if actually used.
The protocols between the generic shell and the "player" module
ought to be as simple as possible.

The problem remains; that understanding what is going on in the
internals of a serious program is extremely difficult, and understanding
is greatly assisted by a quality user interface that is specifically
programmed to assist that investigation, so there is tremendous opportunity
to resume spinning under the guise of assisting the investigation.

---

Re java contributions, I have a bean for board display that is quite flexibe,
a SGF package, and my tsumego perfect play database on offer, see
http://www.andromeda.com/people/ddyer/go-program.html