Re: [computer-go] Go Board Library
On 12/16/2006, £ukasz Lew [EMAIL PROTECTED] wrote: http://www.mimuw.edu.pl/~lew waiting for Your comments :) Thanks for sharing it! I'll definitely give it a try. Urban ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] libgoboard v 0.93.1
On 12/18/2006, £ukasz Lew [EMAIL PROTECTED] wrote: Hi, I implemented most of the requests. The ChangeLog is available next to the library on my webpage: http://www.mimuw.edu.pl/~lew/ The highlights: - MC playout (random, no self eye filling) implemented - 37 kpps on my laptop Celeron M 1.4 GHz - 57 kpps on AMD Opteron 2.2 GHz I haven't had much time to look at the code, but it seems like the board is hard coded to 9x9. How easy is it to change the size? Do I just have to change the boardsize constant (resp. make it into a variable if I want to set the board size for each game played by the bot.) or is there more to be done? Urban ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] libgoboard v 0.93.1
On 12/18/06, Urban Hafner [EMAIL PROTECTED] wrote: On 12/18/2006, £ukasz Lew [EMAIL PROTECTED] wrote: Hi, I implemented most of the requests. The ChangeLog is available next to the library on my webpage: http://www.mimuw.edu.pl/~lew/ The highlights: - MC playout (random, no self eye filling) implemented - 37 kpps on my laptop Celeron M 1.4 GHz - 57 kpps on AMD Opteron 2.2 GHz I haven't had much time to look at the code, but it seems like the board is hard coded to 9x9. How easy is it to change the size? Do I just have to change the boardsize constant (resp. make it into a variable if I want to set the board size for each game played by the bot.) or is there more to be done? Only the constant :) Urban ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Slow KGS computer Go Tournament
There seem to be other modes having to do with estimated kyu level and game pairing. I guess we need to ignore those for the tournament? Cheers, David On 18, Dec 2006, at 1:00 AM, William M. Shubert wrote: Oops, sorry for not notifying people here about the the change. I assumed that people would notice the change when they logged in for non-tournament use, but people who only use kgsGtp for tournaments would find out at the worst possible time. :-( It is a simple change. Just change tournament=t into mode=tournament as the message you get says. Before I had a bunch of flags, where you could only set one, so it made sense to just have a single my mode is... option. That is the reason for the change. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Slow KGS computer Go Tournament
William, One question - My opponent in the first round somehow got disconnected. A few minutes later botnoid was kicked from the game. What would happen if my opponent came back? Would botnoid automatically rejoin the game or would it now be botnoid that would lose on time? There was a feeling that this might not be handled correctly so I played it safe by writing a script to observe the log file and disconnect/reconnect if it was kicked due to an absent tournament opponent. - Don On Mon, 2006-12-18 at 01:00 -0800, William M. Shubert wrote: Oops, sorry for not notifying people here about the the change. I assumed that people would notice the change when they logged in for non-tournament use, but people who only use kgsGtp for tournaments would find out at the worst possible time. :-( It is a simple change. Just change tournament=t into mode=tournament as the message you get says. Before I had a bunch of flags, where you could only set one, so it made sense to just have a single my mode is... option. That is the reason for the change. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Slow KGS computer Go Tournament thought in the middle
It seems that so far the moves generated by SlugGo are not worth the time they take, and in fact look worse than moves I might expect with shorter time settings. I will be able to check later by replaying this game (with faster lookahead) but forcing SlugGo to continue following this game. Some of Aya's moves look nice. Most other boards look pretty random ... Cheers, David ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Fast Board implementation
All this talk of D inspired me to bite the bullet and try it out myself. (I had been curious to check it out in detail for some time) Sadly, my experience with D is not as shining as others. I tried to take the source of my C++ based bot (housebot) and convert it over. I really like how foreach is handled and the ability to embed unit tests and invariants. I found the contract programming to be more eye candy than practical (but I still used it). On the down side, I noticed a significant lack of documentation and difficult to find get it at my fingertips. Support for an STL equivalent is a few years out of date. minTL seemed the most mature but didn't compile out of the box. The changes to get it to compile seemed minor and it may have been a bad environment set up. On mailing lists, people say that you can use the fancy D arrays for most (but not all) STL containers. The const keyword has been completely removed from the language and makes it hard to force such restrictions on library users. minTL goes far enough to force a const equivalent by using some template parameters and static if's. Beyond that, there's a few things that just drive me batty like no support for a toString property for enums or how my board class's unit test refused to run until other code instantiated it (both makes some sense actually). It's not a bad language, but I feel like it still rather immature. If the docs were good and a templating library was up to date, I probably would have kept playing around. For now I decided to stop... :( -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Dailey Sent: Friday, December 15, 2006 9:17 PM To: Łukasz Lew Cc: computer-go Subject: Re: [computer-go] Fast Board implementation On Sat, 2006-12-16 at 01:47 +0100, Łukasz Lew wrote: On 12/16/06, Don Dailey [EMAIL PROTECTED] wrote: Another report on D programming. It appears that D programs are about 1.5X slower in general - at least for what I'm doing. At one point I reported about 7% slower, but that was a mistake on my part. The difference in programming effort and just plain clean code is quite large - D was well designed and after doing a lot of programming in D, it's a real drag going back to C! Is it? I mean what features of D You've used that make it inconvenient to go back to C? A good part of it is just the extra syntax in C. D isn't expressive like Ruby or Python, but it is expressive enough that you are willing to try something that you might not want to in C without getting a cup of coffee first. Even just the foreach loop, which is a petty thing I admit, but it makes life easier and the code looks cleaner. You can get rid of most of the pointer ugliness. I really like that. My C program is full of functions where you pass pointers to something: MakeMove( position *p, mv_t mv ) p-bd[mv] = 1 + (p-ctm 1); etc... In D you declare arguments as in, out or inout and forget about the pointer syntax such as x, *x blah blah blah. When you have a lot of complex expressions this gets rather convoluted in C. arrays are real nice - you can slice and dice them. You can sort them without all the setup code of c. You can sort arrays of structs by putting a comparison function right inside the structure. Most of these things can be done in C with extra setup code. You don't need foreach loops, you can add a couple of lines of code and get the same functionality in C.But the author of D payed attention to all the little annoyances of C and fixed many of them. And he fixed a lot of stuff that generates bugs. You can write code a little faster in D, but you can write finished bug-free code a LOT faster. It's a whole like of little things like that. Array concatenation, associative arrays, dynamic arrays, etc. Associative arrays is a killer feature even though every language has libraries - it's not the same as having it built into the language. I probably wouldn't use associate arrays in parts of the program that I expect to port to C, but it's hard to live without associative arrays and I've always wanted them in C. Here is a good page to give a quick comparison with C: http://www.digitalmars.com/d/comparison.html - Don But it appears that you can have your cake and eat it too by just making a low level library in C, and doing most of the other stuff in D. D and C are link compatible and there is no effort in making this work - it just works. I have indeed been able to experiment more quickly and easily doing it in D, so I have come up with what seems like a nice formula: 1. Start by doing everything in D. 2. Optimize and experiment. 3. When you are happy, redo the low level stuff in C. It will link right in. 4. You can still continue to experiment. Porting to C from D is quite easy because D is pretty much a cleaned up version of C.
