The difference between academia and engineering is that in academia, you survive by publishing, and in engineering, you survive by not publishing.
Sometimes I feel a little guilty by preying on papers, but then again, those who published them do so to gain notoriety and would like Go programmers to use their ideas anyway.
Yet, I have rarely seen practically useful ideas in comp. Go papers.
Am I overestimating my abilities? I don't think so. I was afraid I would not be able to find a good idea and implement it properly, like I did with Moyo Go's pattern system. Finding and implementing good ideas in Go programming requires fingerspitzengefühl.
Creativity doesn't like to be rushed, but I found a way to do just that: Going on a holiday :) My best ideas come just before waking up properly or just before falling asleep, and "falling from the sky" came something I had been programming my subconcious to find the solution to: The proper, thorough and accurate evaluation of Go positions.
I already explained that in engineering, publishing kills, so I can't go into details. All I can say is that I am convinced that this is huge, and that it is the gateway to making a very strong computer Go program quickly (in less than a decade). Of course you just have to take my word for it, for now. But I am a very happy dude. I have reached the stage where I do not look for ideas in Go papers any more, after five years of R&D, I generate my own now.
What is involved in evaluating a Go position?
1. Getting lots of high-level info on the position (for both colors the moyo/group, aji/group, running space/group, space/group, nt-th order liberties/group, eyespace topology, heuristic territory estimation, heuristic L&D estimation (Benson approximation), ladders, pattern-urgency classification etc. etc. etc.)
2. Accurately using this info in the absolute best evaluation function.
I have figured out how to do (2).
(2) is by far the hardest, (1) "merely" involves counting groups, (order-) liberties, sector lines, Bouzy-influence maps etc. (1) involves some yet-to-be-invented features as well, but that doesn't intimidate me, as I will have a near-perfect (2), which makes it much easier to do the hard bits of (1).
