Re: [computer-go] Big board. Torus ?

2007-02-22 Thread Heikki Levanto
On Wed, Feb 21, 2007 at 07:55:15PM -0600, Matt Gokey wrote: Whether it is a torus or not is irrelevant. The only thing that matters from a go game play perspective is the graph topology. If all points have 4 neighbors the actual physical shape or layout doesn't matter. There can still be

Re: Re[4]: [computer-go] UCT vs MC

2007-02-22 Thread Sylvain Gelly
One more question. Line 23 states: for i:=node.size()-2 to 0 do. The leaf node should be stored in node[node.size()-1], so why do we start at node.size()-2? Is it not necessary to update the value of the leaf node? i:=node.size()-1 would be better you're right :-). Experiments made by people

Re: [computer-go] Big board

2007-02-22 Thread Sylvain Gelly
Hello, Yes, clearly MoGo is doing good stuff inside their playouts. I, too, would like to see if the result of a large-board MoGo playout looks any different from mine. Seems interesting! I'll do that (don't when though), hoping that MoGo's architecture would allow such big boards (not so

Re: [computer-go] Library of Effective GO routines v 0.106

2007-02-22 Thread Łukasz Lew
I do not understand it. Maybe someone does? I've made some tests on 2 core processors, and I have strange results. Some of 2 core processors got results exactly 2x times worse than they should. Why? I have no idea. But 2.8 Ghz 2 core works exactly like my 1.4 laptop. Also version of g++ does

Re: [computer-go] Library of Effective GO routines v 0.106

2007-02-22 Thread Sylvain Gelly
Hello, I do not understand it. Maybe someone does? I've made some tests on 2 core processors, and I have strange results. Some of 2 core processors got results exactly 2x times worse than they should. Why? I have no idea. But 2.8 Ghz 2 core works exactly like my 1.4 laptop. Also version of g++

Re: [computer-go] Library of Effective GO routines v 0.106

2007-02-22 Thread Nick Apperson
if cache is your limiting factor that is usually shared. Also, if you are using processors with hyperthreading, it is possible. Or if bus bandwidth is your limiting factor... but if it is exactly 2x slower that is indeed very odd. My money is on the fact that you have a bottleneck somewhere

Re: [computer-go] Library of Effective GO routines v 0.106

2007-02-22 Thread Nick Apperson
The other thought (kind of silly) but just a pssing thought is that the threads that are benchmarking are keeping a local copy of their count and writing it back at the end (which is allowed) so you are actually getting good performance, but you don't know it because the processors aren't talking

Re: [computer-go] Big board. Torus ?

2007-02-22 Thread Magnus Persson
Quoting Tapani Raiko [EMAIL PROTECTED]: In 3D Go, you need a surface of stones to surround space but just a string of stones peeking in to ruin it. In normal 2D Go, you surround area by strings and ruin area by strings, so there is a nice balance. My guess is that Go in any other dimensionality

[computer-go] Algorithm helps computers beat human Go players

2007-02-22 Thread Ray Tayek
http://today.reuters.com/news/articlenews.aspx?type=technologyNewsstoryid=2007-02-21T181324Z_01_L20533484_RTRUKOC_0_US-SCIENCE-GO.xmlsrc=nl_ustechnology --- vice-chair http://ocjug.org/ ___ computer-go mailing list computer-go@computer-go.org

Re: [computer-go] Big board. Torus ?

2007-02-22 Thread Matt Gokey
Heikki Levanto wrote: On Wed, Feb 21, 2007 at 07:55:15PM -0600, Matt Gokey wrote: Whether it is a torus or not is irrelevant. The only thing that matters from a go game play perspective is the graph topology. If all points have 4 neighbors the actual physical shape or layout doesn't matter.

Re: [computer-go] Big board. Torus ?

2007-02-22 Thread steve uurtamo
I'm not sure I agree with this. I hypothesize that 2d, 3d, 4d, torus, or any other shape is completely irrelevant with regard to game play. The only thing that matters is the graph topology. it is true that the only thing that matters is graph topology. it is also true that graph topology

Re: [computer-go] UCT article

2007-02-22 Thread Richard Brown
Sylvain Gelly wrote: Thank you all for your precise answers! Sylvain p.s. the find out more link at the bottom of your page http://www.inria.fr/futurs/ressources-1/computer-culture/mogo-champion-program-for-go-games is pointing to the wrong place, isn't it? What do you mean?

Re: [computer-go] Big board. Torus ?

2007-02-22 Thread steve uurtamo
If I take a plane, I can draw a 9x9 board on it or a 19x19 board on it. I can also draw the previously mentioned circular / cylindrical board on it. Could you explain how you propose to extract the topology of these, given only the fact that I have drawn them on a plane? excellent point. :)

Re: [computer-go] UCT article

2007-02-22 Thread Sylvain Gelly
What do you mean? You mean you can't access the page, or the content is not informative, non relevant, not interesting? This is the text: (...) find out more But, when I click on the find out more link, it takes me to http://cgos.boardspace.net/ !! Surely that is not what you intended.

Re: [computer-go] Library of Effective GO routines v 0.106

2007-02-22 Thread Sylvain Gelly
So, what should I be looking for in a processor if I want to get the most out of my single threaded UCT program? The best way is to find a friend with exactly the processor you want and try your program on it... The second best is see benchmarks, and find which benchmark is relevant to your

[computer-go] scalability studies with UCT

2007-02-22 Thread Don Dailey
I've been doing some interesting scalability studies with Lazarus. On the big 19x19 boards, along with the help of others, we tested versions of Lazarus against other versions of Lazarus at different levels. We set up individual versions of Lazarus where the weakest version was Lazarus doing

Re: [computer-go] CPU for UTC

2007-02-22 Thread Richard J. Lorentz
Thanks! That one CPU comparison is very helpful. So, indeed, there is a lot more to worry about these days than simple clock speed. Has anybody else done similar comparisons? :) P.S. I'll almost surely pass on overclocking, but I had heard rumors that current CPUs were running well under

Re: [computer-go] Library of Effective GO routines v 0.106

2007-02-22 Thread Don Dailey
Hi Richard, I'm very much interested in core 2 duo performance and would appreciate hearing what others have experienced in this regard. I don't know what OS you use, but here are my experiences so far with Linux: I'm a little disappointed with the speed of a single threaded application on my

Re: [computer-go] Library of Effective GO routines v 0.106

2007-02-22 Thread Don Dailey
On Thu, 2007-02-22 at 17:05 +0100, Sylvain Gelly wrote: So, what should I be looking for in a processor if I want to get the most out of my single threaded UCT program? The best way is to find a friend with exactly the processor you want and try your program on it... The second best is see

Re: [computer-go] CPU for UTC

2007-02-22 Thread Don Dailey
On Thu, 2007-02-22 at 09:02 -0800, Richard J. Lorentz wrote: model name : Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz stepping: 6 cpu MHz : 2660.110 cache size : 4096 KB is the fastest processor for MoGo I have access to. Each processor (there are 2), is

Re: [computer-go] Library of Effective GO routines v 0.106

2007-02-22 Thread Brian Slesinsky
My Mac seems to have a relatively old version of gcc: $ g++ -v Using built-in specs. Target: i686-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5367.obj~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++

[computer-go] documentation for the IGS protocol ?

2007-02-22 Thread Stuart A. Yeates
Does anyone know of a document outlining the IGS protocol? There are a number of programs and servers which support the IGS protocol, including the IGS server. I am trying write a tool to interact with these servers and would prefer not to have to reverse engineer the protocol from the programs,

Re: [computer-go] CPU for UTC

2007-02-22 Thread Sylvain Gelly
Assuming the speed ratio is the same going from 2.4 to 3.4, then I'm getting much less than you.I would like to know why! I agree. Can you tell me which compiler, OS and compiler flag you are using for this? See my other email. Also, why is your P4 3.4 already 1.2 faster than other P4

Re: [computer-go] CPU for UTC

2007-02-22 Thread Eduardo Sabbatella
Perhaps someone wants to implement MC algoritm in a small processor and create am array of PICs or something running MC. :-P (some really cheap PICs runs up to 200mhz these days...) or those programmables chips GPUs? I don't remember the name. MPMC = Massive Parallel Monte Carlo :-) --- Richard

Re: [computer-go] Big board

2007-02-22 Thread Sylvain Gelly
Yes, clearly MoGo is doing good stuff inside their playouts. I, too, would like to see if the result of a large-board MoGo playout looks any different from mine. Hello, I did the experiments, but it seems that the results are not different from those with an uniform random player. Certainly

Re: [computer-go] Library of Effective GO routines v 0.106

2007-02-22 Thread Don Dailey
On Thu, 2007-02-22 at 18:50 +0100, Sylvain Gelly wrote: I'm very much interested in core 2 duo performance and would appreciate hearing what others have experienced in this regard. I don't know what OS you use, but here are my experiences so far with Linux: You seem to have exactly

Re: [computer-go] scalability studies with UCT

2007-02-22 Thread alain Baeckeroot
Le jeudi 22 février 2007 17:00, Don Dailey a écrit : It appears that at 9x9 Lazarus needs more play-outs to equalize with gnugo. However, it also appears that at higher levels the superiority is even greater than in the 7x7 games. This is non-intuitive and probably not really the case - I

Re: [computer-go] Library of Effective GO routines v 0.106

2007-02-22 Thread Hideki Kato
Hello Sylvain and Don, I prefer 32-bit OS as Core series is not better for 64 bit and try not nocona but pentium-m. For overclocking, usually 3 GHz (333 MHz FSB x 9 for E6700) is very easy without core volt doping. -gg (Hideki) Don Dailey: [EMAIL PROTECTED]: On Thu, 2007-02-22 at 18:50

Re: [computer-go] Library of Effective GO routines v 0.106

2007-02-22 Thread Don Dailey
On Fri, 2007-02-23 at 03:54 +0900, Hideki Kato wrote: Hello Sylvain and Don, I prefer 32-bit OS as Core series is not better for 64 bit and try not nocona but pentium-m. For overclocking, usually 3 GHz (333 MHz FSB x 9 for E6700) is very easy without core volt doping. With 64 bits as

Re: [computer-go] documentation for the IGS protocol ?

2007-02-22 Thread Unknown
On Thu, 2007-02-22 at 17:50 +, Stuart A. Yeates wrote: Does anyone know of a document outlining the IGS protocol? There are a number of programs and servers which support the IGS protocol, including the IGS server. I am trying write a tool to interact with these servers and would prefer

[computer-go] Re: documentation for the IGS protocol ?

2007-02-22 Thread Dave Dyer
The NNGS clone on boardspace.net is still running, but completely idle. It would be a suitable place to test clients. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] scalability studies with UCT

2007-02-22 Thread Don Dailey
On Thu, 2007-02-22 at 18:31 +, alain Baeckeroot wrote: Le jeudi 22 février 2007 17:00, Don Dailey a écrit : It appears that at 9x9 Lazarus needs more play-outs to equalize with gnugo. However, it also appears that at higher levels the superiority is even greater than in the 7x7 games.

Re: [computer-go] CPU for UTC

2007-02-22 Thread Chris Fant
Perhaps someone wants to implement MC algoritm in a small processor and create am array of PICs or something running MC. :-P (some really cheap PICs runs up to 200mhz these days...) or those programmables chips GPUs? I don't remember the name. MPMC = Massive Parallel Monte Carlo Yes, I'd love

Re: [computer-go] Library of Effective GO routines v 0.106

2007-02-22 Thread Sylvain Gelly
Hello, 2007/2/22, Martin Møller Pedersen [EMAIL PROTECTED]: The intel compiler is much better I understand and you can get it for linux too, but I'm too cheap to do this. GCC will eventually improve for core 2 duo, hopefully I won't have to wait too long. It is what I have heard for

Re: [computer-go] Library of Effective GO routines v 0.106

2007-02-22 Thread Don Dailey
Ok, so I will probably give it a chance if it's free. I'll let you know if anything interesting happens. I really prefer to stay with GCC but if there is a big difference I will use intel until GCC starts optimizing for core 2, assuming it's usable. I'm not sure when this will happen, it

Re: [computer-go] Library of Effective GO routines v 0.106

2007-02-22 Thread Martin Møller Pedersen
On 22/02/07, Sylvain Gelly [EMAIL PROTECTED] wrote: Hello, 2007/2/22, Martin Møller Pedersen [EMAIL PROTECTED]: The intel compiler is much better I understand and you can get it for linux too, but I'm too cheap to do this. GCC will eventually improve for core 2 duo, hopefully I won't

Re: [computer-go] Big board

2007-02-22 Thread Chris Fant
The difference is small, and only the renormalizations that would show any real differences. Or you could create a chart that tracks board size and average chain size and see if there is any association between the two. Do you agree that that is also a sensible test, David?

Re: [computer-go] Big board

2007-02-22 Thread David Doshay
I will think about that, but I know that the renormalization trick is very sensitive. I find it hard to believe that any other test could be any more sensitive. And I know the basis for the renormalization. One question for both of you: Are these the result of one random playout or are they

Re: [computer-go] CPU for UTC

2007-02-22 Thread Chris Fant
Perhaps someone wants to implement MC algoritm in a small processor and create am array of PICs or something running MC. :-P (some really cheap PICs runs up to 200mhz these days...) or those programmables chips GPUs? I don't remember the name. MPMC = Massive Parallel Monte Carlo Yes, I'd

Re: [computer-go] Big board

2007-02-22 Thread Chris Fant
Are these the result of one random playout or are they from one MC player playing against another (each using many playouts to determine its move)? One MC playout. At 100 playouts per move, generating a 1000x1000 graphic would take something like 95 years to compute, assuming you did not

Re: [computer-go] Big board. Torus ?

2007-02-22 Thread Matt Gokey
alain Baeckeroot wrote: Le jeudi 22 février 2007 14:11, Matt Gokey a écrit : The only thing that matters is the graph topology. A corollary is that on any board that is completely balanced at the beginning with identical number of neighbors for all nodes, any 1st play is equivalent and

Re: [computer-go] Library of Effective GO routines v 0.106

2007-02-22 Thread Hideki Kato
Hello Don, Thank you for the advises but I run 32 bit Fedore Core 5 on [EMAIL PROTECTED] Don Dailey: [EMAIL PROTECTED]: On Fri, 2007-02-23 at 03:54 +0900, Hideki Kato wrote: Hello Sylvain and Don, I prefer 32-bit OS as Core series is not better for 64 bit and try not nocona but pentium-m.

Re: [computer-go] Big board. Torus ?

2007-02-22 Thread Chris Fant
I don't understand. I think everyone is thinking too visually. What does straight mean in the context of go? Only liberties are meaningful. It is isotropic if you stop visualizing the shape and only consider the graph. I think straight would mean that when moving from one node to an adjacent

Re: [computer-go] Big board. Torus ?

2007-02-22 Thread alain Baeckeroot
Le vendredi 23 février 2007 01:19, Matt Gokey a écrit : Here is a thought experiment to test: define the board only logically using a graph (nodes and neighbor nodes). No topological shape and no mesh layout over any shape is needed. If all nodes have exactly four neighbors, there is no

Re: [computer-go] CPU for UTC

2007-02-22 Thread David Doshay
Check out: www.intel.com/go/teraflops Cheers, David On 22, Feb 2007, at 6:10 PM, William Harold Newman wrote: Some serious people are arguing http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.html that, among other things, the sweet spot for performance is down around

Re: [computer-go] Big board. Torus ?

2007-02-22 Thread Matt Gokey
Tapani Raiko wrote: Matt Gokey wrote: I'm not sure I agree with this. I hypothesize that 2d, 3d, 4d, torus, or any other shape is completely irrelevant with regard to game play. The only thing that matters is the graph topology. A corollary is that on any board that is completely balanced at

Re: [computer-go] Big board. Torus ?

2007-02-22 Thread Matt Gokey
Nick Apperson wrote: I considered making a version of go that plays with tetrahedral geometry. It is a 3D arrangment where all nodes have 4 neighbors and the angles between each are 109 degrees. Its connection properties though are very different because of the way it it layed out. Hence, I

Re: [computer-go] Big board. Torus ?

2007-02-22 Thread Matt Gokey
Matt Gokey wrote: alain Baeckeroot wrote: Le jeudi 22 février 2007 14:11, Matt Gokey a écrit : The only thing that matters is the graph topology. A corollary is that on any board that is completely balanced at the beginning with identical number of neighbors for all nodes, any 1st play is

Re: [computer-go] Big board, ++physics

2007-02-22 Thread alain Baeckeroot
Le jeudi 22 février 2007 01:16, David Doshay a écrit : It is pretty clear to me that, if the analogy to MC simulations in magnets is of any value, the temperature of the Go game you show is hotter than optimal. If the temperature were at the transition temperature, then each of the

Re: [computer-go] Big board, ++physics

2007-02-22 Thread Ray Tayek
At 09:03 PM 2/22/2007, you wrote: 4/ shape/size resonance (un)fortunately the 19x19 size is just the critical size to have problems. -17x17 is too small, corners influence is too strong, it is quickly possible to take the border. (= 3 bubbles) -21x21 is too wide, it is not possible to