I am relatively new to Go and am also a programmer. So naturally, the topic of programming computer Go interests me. I have done some Googling and can't find many forums dedicated to Go developers. I have seen developers in discussion on this forum. I am also subscribed to the mailing list at computer-go@dvandva.org, but this doesn't seem to be very active.

Am I missing something? I guess I expected to see much more activity in terms of discussion. Is the problem that there aren't many new ideas to be discussed at this point? Or is it that most development is commercial, so people don't want to share IP?

Hopefully I am just not using the right Google search terms.

Thanks!

Over the past two decades its moved from people doing it all alone to research groups at universities. I would suggest just looking them up, reading the papers they are producing, and just contacting them directly.

Most of them are just people trying to get their degrees, they are quite friendly, but working hard and are very busy.

You can download pachi's source code here, maybe this can get you started:
http://pachi.or.cz/

Ah. This makes sense. There is definitely a lot of information available out there.

I guess when I started looking, I expected to see a forum like this one from the Google AI challenge. http://forums.aichallenge.org/viewforum.php?f=24. But that was a different situation. So it makes sense that if most Go programming work is happening in academia, in research groups, the discussions are probably more among the members of those groups and at conferences. Also the papers being published as you mentioned.


Thanks!

The discussion on the computer go forum is unusually slow right now. Check the archives for last fall: there was a lot of discussion and it seems newcomers were pretty welcome.

_________________
Occupy Babel!

I can also suggest, on the KGS server, there is a "Computer Go" room under the Social heading. This is probably a good place to go to discuss robot players. Also, many robot players play in this room so you can watch them as well.

The amount of technical discussion is low though, most people are just fans or antifans of the robots.

Welcome to go programming.

The computer-go mailing list is definitely the place where the programmers meet and talk. It has not been very active in the past days, but it is usually more active.

You can also find many papers there:
http://www.citeulike.org/group/5884/library
But it is not really up to date with all the most recent papers. For instance, this one might be interesting to you:
http://www.cameronius.com/cv/mcts-survey-master.pdf

Rémi

I'm tempted to give a try to writing a completely naive implementation of MCTS just for fun (I'd love to have my program beat me in 9x9... even if it is with 5 stones)... If only I knew I'd finish it... At least it sounds as fun as approximating images with triangles (I did with simulated annealing,) but there's a lot to read (and implement) before I can get hands-on. And decide whether I want speed (C, Forth) or a REPL (Lisp, Python, Forth). Yes, Forth has both, but I am not proficient enough for a big task I think

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net

I am also thinking about programming a simple AI to tinker on in my free time. At this point I am thinking that algorithms for things like score estimating and determining life/death of groups will be fun to play with. For move generation, I figure I will start with a simple random move generator and move on from there...

Have you ever looked at D? http://dlang.org/? I recently started playing with this and I really wish it could pick up more popularity. It compiles to a native binary with near-C performance. But is much cleaner (IMHO) than C code. I find it very easy to jump in and write code without getting bogged down in some of the details that C requires. And for OOP, I prefer it over C++. Not trying to stir the pot here, just wanted to point out something that people might have fun looking at.

My only indirect contact with D is via playing Torus Trooper, a game written in this language... I'm proficient enough (i.e. the small things don't bother me anymore) with C that I can start coding without much trouble... And after having to solve doubts by ~150 students with their programming assignments (let's play catch the segfault!) finding obvious mistakes even in my own code is straightforward enough. But thanks for the pointer! D sure looks like a fun language, but it would steer me in a direction I feel filled with C already

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net

Yeah, I did some C professionally a few jobs back and also have played with building neural networks in C. There is definitely something gratifying that comes from working in one of the 'lower' level languages.

Selecting a language for implementation is something that should be coming later in the process.

First you design your solution and at this stage should be at the level of abstract operations upon abstract data structures. Whatever cleanly results in a program that plays go. If you do this right you won't (in effect) be coding the program but coding real implementations of these operations and data structures. A great deal of the art of designing easy to understand and maintain programs depends upon appropriate choices about the level of abstraction.

One advantage is that you can build "drivers" to test each component (that it correctly implements the abstraction). In which case if your design is correct your program will be correct.

I already have quite an idea of how I want the program to work, but anyway, if I want to write a program that relies heavily on text processing, as much structuring as I gave my thoughts, I'd have to choose Python over C. Or if I were to write heavily recursing programs working on linked lists, I'd pick Lisp, hands down. Regardless of the design.

(Edit) I think a quote from Paul Graham's FAQ fits in here

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net

I strongly disagree. And I was never a "people manager".

If you design "ad hoc" in the manner descibed then even should you end up with a correct program, an easily tested program, an easily maintained program, etc. (all of which I doubt) you will certainly end up with a program whose bits and pieces are not usable as building blocks in other programs.

You gave an example of a type of program, one making heavy use of singly linked lists. Yes of course, that's the primary "variable type" of LISP family languages. And were your style of design/coding to write everything ad hoc using a language like C would be harder. But if you design/writing style were at the abstract level (and you were using C as your implementation language) then once in your programming career would you have defined the structures and functions for "singly linked list". Thereafter you would know from where you could "lift" these.

When I say I wrote about 300,000 lines of code in my day I mean lines of finished programs, not necessarily typing in that many. That means many times "writing" a new "special program" (for some ad hoc purpose) being able to take some old one of a thousand lines or so and by changing perhaps a hundred lines have a new (quite different) program of a thousand lines or so. Or combining pieces of size a hundred lines or so from several older programs and just adding/removing bits. Usually only 10-15% of a new program would actually be completely new. I had accumulated a very useful personal library of commonly reusable bits and pieces. ROFLOL my last week or two of work was to annotate it (add a member describing the sorts of uses the various library members might be good for) so it would be still useful once I was gone and I couldn't simply tell some programmer who came to me asking "Mike, how do I do this?" that they should take this or that member of my library as a starting point and modify it to the new problem.

My programs were always very well commented not because I took the time to add comments but because the comments existed before the code. I would write the design in words in whatever format was accepted as comments by the language of implementation.

Programs should be built out of well defined and easily tested pieces, pieces whose correctness can be tested outside the context of the entire program. Makes debugging a whole lot quicker and easier. Especially with big programs!

I do agree with Mike that there is a huge value in a pre-coding design phase at the "level of abstract operations upon abstract data structures". I also prefer a strong modular design with separation of concerns and a focus on reusable components.

I don't think that Mike is saying that every part of your program should be designed with flowcharts and pseudo-code before the real coding takes place. But by laying out your basic framework, you can ask your questions like:

* How hard would it be to start with a GTP interface, but then add the ability to load SGF files later.
* Can I start with a simple random move generator, but then add a module for MCTS later. (you may still want the random option to be available for quick testing of other modules)
* How can I switch between rule sets?
* And MANY more...

For myself, I want to be able to easily add modules with little, or ideally no, change to other modules. I have been outlining a framework and identifying what the core data structures and functional units will be. I have settled on D for the bulk of my components. But I am also leaving the system flexible so that it would be relatively easy to implement some things like visualizations using something like PHP through a browser interface.

Mike:
This discussion goes well beyond computer go development. Your view has been challenged lately by many different agile methodologies which prioritize development and refactoring over long-term planning.

I won't dig deeper because you have probably heard about this before, I'll leave a quick link for those who have not:
http://en.wikipedia.org/wiki/Agile_software_development


Personally, I've changed my mind over the years from "start coding", to "plan thoroughly" and later to "don't make plans you know you won't follow".

I've always been pretty much halfway in between. Plan a bit, start a framework as an example to see if it still makes sense, and then go back to planning on each individual part. You end up in a path where you do planning->code->test->planning->code->test... etc until done.

Last month I started using Greenfoot to make a 9x9 'Tibetan' Go program. (not an AI)

_________________
North Lecale

Mention of things like "flowcharts" and "pseudocode" (though that is closer) indicates many of you don't understand what I mean by "abstract design". For example, using a flowchart implies that you have already chosen "process" over "evaluation" (of a function).

On way of thinking about this is the reverse of "coding". Try to visualize the "machine" that just happened to have as its primative machine instructions and data storage exactly what you would want to make solving the problem trivial. Once you have reduced the problem to this abstract machine using its abstract operations/evaluations on the abstract data structures you have broken the problem part into pieces that are probably the right size. You now just code whatever implements these abstract operations/evaluations and data structures on your real machine.

The danger of "jumping right in" is that the way the problem is defined (or the way that you see it) might lead you to make premature choices. Choices that mean your solution will be clumsy, inefficient, slow, hard to test, etc.

In my experience, that approaches frequently leads to "perfectly solving the wrong problem".
Especially in home-made projects, one should not be too attached to the initial requirements in order to keep the motivation high with new and different ideas.

With that statement I am beyond disagreement. I don't comprehend it. What do you mean by "wrong problem"? How would coding enable you to discover this? You set out to write a go playing program but decided you really wanted one that played chess? Do bookkeeping?

The definitions/decisions about what your program is supposed to do have to come long before you dive in to code it. Nor does it make all that big a difference whether this goal is set by "management" or yourself. ROFLOL back in the days when it was management deciding what I would be working on rarely was that fixed in stone (I was a critical resource and so only very rarely ended up doing what was planned for the next six months --- I think only Y2K went as planned and even then I had to jump over to redo the first "done by tools" system when it went into production and serious problems surfaced).

After retiring I decided what programming to do and in what languages (when you are already fluent in half a dozen and can at least read most any adding a new one is easy). But if I chose to write a progam to do this or that (say a finite implementation of the 2nd Lempel-Zev Universal Data Compression Algorithm directly from the definition -- the "case problem" I chose for deciding if I had learned C) I would be disappointed (consider it a failure) if did something else. Even if that something else was a perfectly good (but different) compression algorithm. Or even the very useful/practical closely related alternative that used a fixed size dictionary (instead of one starting at the character set and growing to some finite max size). Because not the problem I chose to solve.