The Final Countdown

I succeeded in making an obscenely fast nth-order liberty delta-updater, and soon it's time to make what Michael Reiss' debug version of Go++ has: A plethora of debug windows.

Mick was so kind to send me his highly intimidating debug version of Go++, perhaps as a subtle form of psychological warfare amongst Go programmers ;-). Programming Go is one of the most complex endeavors on the globe, comparing to neurosurgery as neurosurgery compares to pruning roses. Pruning roses properly requires talent, skill and years of experience and so does neurosurgery - on a higher level, but the level of knowledge, talent and skill required for any kind of surgery pales next to what's needed to design and implement a state-of-the art Go program. So far, the only Western folks who succeeded were dan-level players or close and:

1. A designer of microprocessors (Many Faces of Go)
2. A former Microsoft programming wizard (SmartGo)
3. A dual PhD in Physics and Neural networks (Go++)
4. Another top expert in neural networks, working for a government (WinHonte)
5. A team of various expert developers with even a comp. sci professor in their ranks (GNU Go)

I have no education or Go ranking to boast of, so it's going to be interesting.

"The Final Countdown" refers to the firing up of the move engine. It's fueling up, to use a metaphor. As I said, I need to code up quite a lot of introspection stuff, because I'm not under the illusion that the beast will work as it should fresh from the press. And even if it does, I want to be able to verify this reliably and quickly, and be able to see where things go wrong.

So I'll need test code and GUI code that dumps the internal state. Although the state machine is coded with insane efficiency in mind (perhaps on a par with Vincent Diepeveen's branchless move generator for Chess), I expect to do a lot of optimization and I need to know immediately when I broke something.

I think that coding the debug- & test framework will take up a couple of weeks at most - I'm in the process of slowly moving domicilie - and debugging can take anything up to several months, depending on how many fundamental flaws in my design assumptions surface. I waited quite a few years before I started with the tactical module because haste makes waste.

Browsing the comp. Go mailing list, I was surprised to find a few colleagues mentioning how their tactics module took more than a second to generate and evaluate a position. I am aiming for at least 50,000 nodes/s. on my hardware (that's just a very rough estimate of what I think should be possible). And not just any nodes but highly relevant ones. Pruned in a clever way.

I won't use a hand-coded expert-system to prune the tree, I'll let automatic learning decide which points are interesting to play on. I have already done that very successfully with my best selling Moyo Go "pattern expert" software, but the plausible move generator I am making now will be specialized for tactical situations.