> Jason, can You tell me why You don't want to use libego instead? > Actually this is open question to all comp-go readers. > > Is libego too complicated? Do You have problems with compilation? > Or You are not comfortable with the GNU license? Any other reason?
I've been studying and experimenting with libego. I will probably write my own monte carlo implementation from scratch soon (though I intend to follow many of your coding decisions). Two big reasons. First I have a lot of C++ code (for patterns, tactical search, etc.) that I still want to use. It is incompatible with libego at the low level (e.g. way of describing board coords). Second, the GPL virus license. If it was BSD-like I'd give more consideration to switching to using libego at the low level, and alter all my other code (because libego is quick, and because of all the usual open source advantages, which could be summarized as: "it will only get better"). I'd also be more likely to contribute code. However, I know my views on BSD vs. GPL are stronger than most people. Documentation is weak, but it only took me a handful of hours to go through the code line by line, taking notes, to work out what was going on. Being on sourceforge would be good. Removing all global variable references would be good. Use of templates (i.e. policy helper classes) instead of #defines would be good. None of these would stop me using libego though. Jason House also mentioned "hard coding to a set board size", I think libego can be used at least up to 19x19, just by changing the "board_size" setting in board.cpp (it also supports hexagonal boards). Or did you mean being able to make one binary for all board sizes? I feel that that flexibility doesn't justify the performance hit. Darren _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
