Re: Eureka!

[Jeffrey Greenberg <jeffg@xxxxxxxxxx>]

David F. and others have been very generous with their descriptions, though I
wish they would share more source code of their "infrastructure".

Fotland and Wilcox have described in great detail the pattern portion of their
programs: usually as a means to play an immediate response or as a means to
generate candidate moves for alpha-beta evaluation.

Is anyone really making much money at this?  Is that really the motivating
factor here?

I think go programming so far is more about managing and evolving complex code
structures than anything else.   Broadly and baldly put, I would say there are
no new fundamental algorithms in any of the work.  Programmers are struggling
with applying the existing search mechanisms and pattern recogition algorithms
to their human intuition about how they think about playing go.   It's about
managing the complexity of the numerous subcases: handling ladders, how to
connect, how to cut, etc.

Jasiek asks for David to describe more the "strategy" of his program, by which
he might mean the "when" questions, such as, "how do you know when it is time to
connect vs play over there".   That is we seem to describe these programs in
terms of the actions the program can perform: detect this, cut that, block
there.  We don't describe the integration of these beyond referring to arbitrary
weightings of one action over another as part of an lookahead search evaluation
function.

As far as these expert style programs go, I'd like to see more about the overall
program structure, than the micro level data structures (such as revertable data
structures) which I think are already well-known.  What is/are the organizing
principle/s at a more global level? How are revertable data structures are
integrated into a complete engine handling many subcases and interactions
between structures?  The advance here is more about software engineering
innovation than algorithm innovation.   I suspect that these programs are huge
agglomerations of code, cobbled together in an ad hoc basis; where organization
is really supplanted by discovering special cases that one overlooked; by
'tuning' and hacking.  Is this true?

The new stuff, the algorithms, are really the exploration of the lesser known
techniques: machine learning, neural nets, gp, simulated annealling, HMM, etc.
The elaboration and application of computing techiques to a difficult problem,
the search of a grand scheme that will "solve go" by making it tractable and not
filled with the effort of organizing an army of programmers to handle special
cases.

And if our strategy to solve go revolves around the psychology of programming,
then we're really lost.  I refer to:

>  David Mechner wrote:
> >I think there's a trap for all of us in computer go, which is the
> >impulse to put lots of time and effort into things that we know how go
> >about doing - like interface, or optimizing for memory and cpu time -
> >instead of the things that are hard and confusing - making the
> >computer play go.

to Bob Merkin's  response:

> Remember that while we're trying to make a computer play Go, it's still a
> human doing the programming, and heed must be paid to the emotional nutrition
> a human requires. Diverting one's attention from time to time to cut-and-paste
> chores -- to progress where progress is more easily available -- treats the
> ego to little successes where more profound breakthroughs may at that moment
> simply not be available.

and my own: "I don't want to write incremental data structures because I find it
boring."

These are the bumps in the road.  Let's get real.

regards,
jeffrey

--
Jeffrey Greenberg
Mgr. Aegis Adv. Dev.
Acuson Corp.
www.ultrasound.com
www.acuson.com
650-694-5422