[computer-go] June KGS Computer Go tournament: 19x19, an hour each
We all think about UCT all day long, ;-) but universal time is called UTC. The acronym is far from obvious, because: The International Telecommunication Union http://en.wikipedia.org/wiki/International_Telecommunication_Union wanted Coordinated Universal Time to have a single abbreviation for all languages. English http://en.wikipedia.org/wiki/English_language speakers and French http://en.wikipedia.org/wiki/French_language speakers each wanted the initials of their respective languages' terms to be used internationally: CUT for coordinated universal time and TUC for temps universel coordonné. This resulted in the final compromise of using UTC. as I quoted from http://en.wikipedia.org/wiki/Coordinated_Universal_Time ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Efficiently selecting a point to play in a random playout
Lukasz Lew wrote: Is libego too complicated? Do You have problems with compilation? Or You are not comfortable with the GNU license? Any other reason? I only wanted to compare performance ( and see what good ideas you had ;-) ) but could not compile libego. Neither with Microsoft Visual Studio nor with Borland Turbo C++. I am 100% Borland because of the ease of assembly language implementation. Borland passes parameters in CPU registers in a documented way and has an extremely straightforward use of local variables and record structure from asm source code to write things easily that work on the first run. At least for Windows programmers, providing a solution that compiles with major IDEs would help. I assume what you do is standard in Linux, but the things the compiler did not understand neither did I, and I could not find the time for googleing. Anyway, I think a go board system is way too important to be universal. I already have a board system in GoKnot that surely outperforms most of the current programs and my new board system I call HBS (Hologram Board System) does not copy a single line from the old one. I call it a hologram because, as in a hologram, each part contains information about the whole picture. In my board, each cell contains a mask of its nearest neighbors. When you place a stone, everything is updated by automatically written assembly language functions. These functions do not have variables except CPU registers and the board, do not have conditional jumps or loops, of course, no stack frames, of course support multi-threading, etc. The board is *never* rescanned whatever happens. Placing a stone on a 31x31 board is not a clockcycle slower than on a 9x9 board (these are my limits) assuming it finds the same chains. Every bit of info on the board is only updated if it may have changed and only once. With this board I will be able to try things that cannot be tried with libego, but as Don said, If you have a hammer, everything looks like a nail., for lots of methods not using shapes my board is way too heavy, (although possibly faster than most in small pattern modes) so I will write engines with shapes (and Statistics) for a while. Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Efficiently selecting a point to play in a random playout
On 5/30/07, Jacques Basaldúa [EMAIL PROTECTED] wrote: Lukasz Lew wrote: Is libego too complicated? Do You have problems with compilation? Or You are not comfortable with the GNU license? Any other reason? I only wanted to compare performance ( and see what good ideas you had ;-) ) but could not compile libego. Neither with Microsoft Visual Studio nor with Borland Turbo C++. I am 100% Borland because of the ease of assembly language implementation. Borland passes parameters in CPU registers in a documented way and has an extremely straightforward use of local variables and record structure from asm source code to write things easily that work on the first run. At least for Windows programmers, providing a solution that compiles with major IDEs would help. I assume what you do is standard in Linux, but the things the compiler did not understand neither did I, and I could not find the time for googleing. Could not compile libego is not a very helpful error message. What exactly did the compiler complain about? My guess is that you don't have the required boost libraries installed. Anyway, I think a go board system is way too important to be universal. I already have a board system in GoKnot that surely outperforms most of the current programs and my new board system I call HBS (Hologram Board System) does not copy a single line from the old one. I call it a hologram because, as in a hologram, each part contains information about the whole picture. In my board, each cell contains a mask of its nearest neighbors. When you place a stone, everything is updated by automatically written assembly language functions. These functions do not have variables except CPU registers and the board, do not have conditional jumps or loops, of course, no stack frames, of course support multi-threading, etc. The board is *never* rescanned whatever happens. Placing a stone on a 31x31 board is not a clockcycle slower than on a 9x9 board (these are my limits) assuming it finds the same chains. Every bit of info on the board is only updated if it may have changed and only once. Funny that. We store 16 bits per point, where the contents of the 8 neighbours is encoded. Actually, in order to get the content of a particular point, we ask its neighbour on the right :). John came up with this and other ideas, like a method to detect if a string is in atari and to find its last liberty in constant time. We don't rescan the board either. Well, only once per simulation, but that's not in the critical section. The only thing you are doing that we are not is using assembly, but I'd rather keep things flexible and portable at this point. Oh, I would be curious to see how you remove a captured string with no loops. With this board I will be able to try things that cannot be tried with libego, but as Don said, If you have a hammer, everything looks like a nail., for lots of methods not using shapes my board is way too heavy, (although possibly faster than most in small pattern modes) so I will write engines with shapes (and Statistics) for a while. The reason we don't use libego either is similar. We need a completely different underlying structure to be able to pick random moves following the distribution we want. I don't think Lukasz can do anything to his library so it would satisfy a significant fraction of programmers, since we all have different needs. Álvaro. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] analysis of UCT and BAST
I have updated the BAST paper, providing additional comparison with UCT, as suggested by one person in the list. See: https://hal.inria.fr/inria-00150207 Basically, in the considered examples, BAST with an appropriate smoothness sequence performs always better than both UCT and Flat-UCB. Now, the best smoothness coefficient is always smaller than the constant corresponding to the true smoothnes of the tree, and sometimes very close to 0 (which corresponds to UCT). Since go is way more complex than the problem of optimizing a simple 1-d function, I would say that no theoretical work could predict whether BAST would do better than UCT or not, in Monte-Carlo-go. Best, Remi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Efficiently selecting a point to play in a random playout
Álvaro Begué wrote:
At least for Windows programmers, providing a solution that
compiles with major IDEs would help. I assume what you do is
standard in Linux, but the things the compiler did not understand
neither did I, and I could not find the time for googleing.
With 1.08 version of lego and Turbo C++, there are too many errors
related to namespaces, system libraries etc.
With *wx-Devcpp* http://wxdsgn.sourceforge.net/ windows compilation is
relatively straightforward. Create a new project file (main.cpp and
gtp.cpp is enough for benchmarking), Replace get_seconds(), install
boost library (a package is available at devpaks.org if you don't want
to compile the library) and you are done.
---
float get_seconds () {
return double(clock()) / double(CLOCKS_PER_SEC);
}
I know this is not a precise way of calculating time, but if it is good
enough for fruit, it is good enough for me.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Efficiently selecting a point to play in a random playout
On 5/30/07, Berk Ozbozkurt [EMAIL PROTECTED] wrote: Álvaro Begué wrote: At least for Windows programmers, providing a solution that compiles with major IDEs would help. I assume what you do is standard in Linux, but the things the compiler did not understand neither did I, and I could not find the time for googleing. Hey, I didn't write that! :) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] analysis of UCT and BAST
I'm not sure whether You have noticed, but my student made an empirical comparison between BAST, UCT and other formulas. It can be found here: http://students.mimuw.edu.pl/~fg219435/Go/ Best Regards, Lukasz Lew On 5/30/07, Remi Munos [EMAIL PROTECTED] wrote: I have updated the BAST paper, providing additional comparison with UCT, as suggested by one person in the list. See: https://hal.inria.fr/inria-00150207 Basically, in the considered examples, BAST with an appropriate smoothness sequence performs always better than both UCT and Flat-UCB. Now, the best smoothness coefficient is always smaller than the constant corresponding to the true smoothnes of the tree, and sometimes very close to 0 (which corresponds to UCT). Since go is way more complex than the problem of optimizing a simple 1-d function, I would say that no theoretical work could predict whether BAST would do better than UCT or not, in Monte-Carlo-go. Best, Remi ___ 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] analysis of UCT and BAST
Łukasz Lew wrote: I'm not sure whether You have noticed, but my student made an empirical comparison between BAST, UCT and other formulas. It can be found here: http://students.mimuw.edu.pl/~fg219435/Go/ Best Regards, Lukasz Lew Hi Łukasz, You write that EGO_BAST seems to be a bit more effective against GnuGo, but I cannot see any test result of EGO_BAST against GNU Go on your page. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
