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
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
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
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
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++
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
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
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
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
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.
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
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?
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. :)
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.
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
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
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
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
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
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
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++
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,
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
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
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
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
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
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
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
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
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/
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.
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
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
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
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
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?
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
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
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
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
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.
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
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
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
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
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
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
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
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
50 matches
Mail list logo