Gunnar Farnebäck wrote:
Markus Enzenberger wrote:
> I connected Fuego configured with CGOS rules. After a while it
> terminated, because Fuego returned an error response to a play command
> with a move that violated the positional superko rule. (By default,
> Fuego does not accept illegal moves t
Markus Enzenberger wrote:
> Gunnar Farnebäck wrote:
>> To do that, just point your regular cgos client to trac.gnugo.org,
>> port 6867.
>
> what rules does GNU Go use in the 6x6 analysis?
Uh, whatever I happened to remember to set it to. :-)
In this case that would be area scoring, no suicide, s
On Fri, Oct 3, 2008 at 11:31 AM, Markus Enzenberger
<[EMAIL PROTECTED]> wrote:
> Gunnar Farnebäck wrote:
>>
>> To do that, just point your regular cgos client to trac.gnugo.org,
>> port 6867.
>
> what rules does GNU Go use in the 6x6 analysis?
>
> I connected Fuego configured with CGOS rules. After
Gunnar Farnebäck wrote:
To do that, just point your regular cgos client to trac.gnugo.org,
port 6867.
what rules does GNU Go use in the 6x6 analysis?
I connected Fuego configured with CGOS rules. After a while it
terminated, because Fuego returned an error response to a play command
with a m
Is Microsoft now selling computers? Interesting...
Let me chime in with my congratulations to David.
Mark
On 2-okt-08, at 20:52, Darren Cook wrote:
investment. If we can find corporate sponsors, it should not be hard
to gain access to such hardware. Reading between the lines, I think
Hey,
That's really cool! I like it. Are you going to process the file
later similar to what I did with the Leela games?
- Don
On Fri, 2008-10-03 at 01:23 +0200, Gunnar Farnebäck wrote:
> At http://trac.gnugo.org/6x6.sgf you can find an ongoing analysis of
> 6x6. This is a very big and quite
>From all we know so far it is most likely that perfect komi is 7.0.
Even numbers lik 6.0 and 8.0 are unlikely because they always require
a seki with an odd number of shared liberties (in all optimal lines!).
Since IMO the first player should have a chance to win it seems
natural to set the komi
Ingo Althöfer wrote:
> Gian-Carlo Pascutto wrote:
>> I'd have some preference for playing the decisive game
>> with komi = 6.5, but apparently thats not possible on KGS.
>
> But that should not be a problem, as long as the operators
> do not believe in the final verdict of KGS.
But KGS will tel
On Fri, Oct 3, 2008 at 12:13 AM, Gian-Carlo Pascutto <[EMAIL PROTECTED]> wrote:
> I'd have some preference for playing the decisive game with komi = 6.5,
> but apparently thats not possible on KGS. I think with komi = 7.5 white
> is scoring very high (too high?) in the top games.
Last year (when t
>> I think with komi = 7.5 white
>> is scoring very high (too high?) in the top games.
> ...
> Looking only at games among the top 5 rankers
> there are 20 games so far (including two tiebreak-games)
> with 15 wins for White and 5 Wins for Black.
>
> Looking at all games among the top 7 rankers
>
> investment. If we can find corporate sponsors, it should not be hard
> to gain access to such hardware. Reading between the lines, I think
> some Microsoft wunderkind may be backing Dave Fotland.
It seems Microsoft are selling such hardware and approached David while
looking for some applicati
A couple of hours.
/Gunnar
Michael Williams wrote:
Very cool. How long has this been going on?
Gunnar Farnebäck wrote:
At http://trac.gnugo.org/6x6.sgf you can find an ongoing analysis of
6x6. This is a very big and quite raw sgf file where each node has a
comment block looking like this:
Very cool. How long has this been going on?
Gunnar Farnebäck wrote:
At http://trac.gnugo.org/6x6.sgf you can find an ongoing analysis of
6x6. This is a very big and quite raw sgf file where each node has a
comment block looking like this:
0
-2.5: 0 4 black
-0.5: 5 9 black
1.5
At http://trac.gnugo.org/6x6.sgf you can find an ongoing analysis of
6x6. This is a very big and quite raw sgf file where each node has a
comment block looking like this:
0
-2.5: 0 4 black
-0.5: 5 9 black
1.5: 9 10 black
3.5: 9 34 white
5.5: 38 20 white
7.5: 22 7 white
9.5: 6
time left in seconds
Cheers,
David
On 2, Oct 2008, at 3:12 PM, Peter Drake wrote:
Here's the beginning of the SGF file of a game I played on KGS:
(;GM[1]FF[4]CA[UTF-8]AP[CGoban:3]ST[2]
RU[Japanese]SZ[19]HA[2]KM[0.50]TM[1800]OT[5x30 byo-yomi]
PW[mundungus]PB[zj]WR[5k]BR[7k]DT[2008-10-01]PC[T
Brilliant! Thank you, both of you, Peter and Claus!
-Mike
Claus Reinke wrote:
Now, for the technical matter: Could somebody please point me to a quick rundown of how modern
Go engines exactly utilize multicore environments and the workload is segregated and
distributed? I don't have any sig
I wonder if CGOS-like tournaments could be distributed?
Instead of an author's single machine playing 1000 games over a long period of
time, programs would be distributed over hundreds or thousands of computers,
which would agree pairwise to play each other, enabling the testing of many
variati
>> Now, for the technical matter: Could somebody please point me to a quick
>> rundown of how modern
>> Go engines exactly utilize multicore environments and the workload is
>> segregated and
>> distributed? I don't have any significant knowledge on that, so any
>> pointers would be much
Hideki Kato wrote:
Don Dailey: <[EMAIL PROTECTED]>:
On Thu, 2008-10-02 at 19:17 +0200, Michael Markefka wrote:
So, when are we going to see distributed computing? [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED] With Go engines that scale well to increased
processing capacity, imagine f
Don Dailey: <[EMAIL PROTECTED]>:
>On Thu, 2008-10-02 at 19:17 +0200, Michael Markefka wrote:
>> So, when are we going to see distributed computing? [EMAIL PROTECTED],
>> [EMAIL PROTECTED], [EMAIL PROTECTED] With Go engines that scale well to
>> increased
>> processing capacity, imagine facilita
Also you have to look at the amount of computation per unit communication. For instance factoring huge numbers is an excellent application for a grid because
with just a few bytes of data, you can keep a CPU busy for a very long time. Regular Go programs don't fit this model. Maybe there someth
Here's the beginning of the SGF file of a game I played on KGS:
(;GM[1]FF[4]CA[UTF-8]AP[CGoban:3]ST[2]
RU[Japanese]SZ[19]HA[2]KM[0.50]TM[1800]OT[5x30 byo-yomi]
PW[mundungus]PB[zj]WR[5k]BR[7k]DT[2008-10-01]PC[The KGS Go Server at
http://www.gokgs.com/]AB[pd][dp]RE[W+Resign]
;W[pp]WL[1794.929]C[
Here's a start:
http://hal.inria.fr/docs/00/28/78/67/PDF/icin08.pdf
Gelly et al, The Parallelization of Monte-Carlo Planning
Peter Drake
http://www.lclark.edu/~drake/
On Oct 2, 2008, at 2:39 PM, Michael Markefka wrote:
Now, for the technical matter: Could somebody please point me to a
qu
I think I'll respond here as not to further detract from David
congratulory thread. :)
While not addressing the replies separately, rest assured that I've read
them all.
Quickly picking up on what Claus wrote here, I agree that there might be
some kind of "prestige angle" to exploit to get som
Don't forget that we are already using machines with thousands of nodes
and so to really benefit from something like boinc you would have to do
quite a bit better than this.
And if more than one of us were to do it, we would be competing for
resources with each other, not to mention the other inte
sure, this would work much better, and is easy to implement
(diameter is log(# nodes) if you set it up as an expander!).
but writing it from scratch is a bit of a burden. i may have
a project like this next semester for my networking class, if so,
we can tack the rest onto it if anyone's interest
I took all the games played by Leela in my 6x6 experiment and applied
mini-max to them, taking the statistics at various depths into the
games.
Don't know if there are bugs here or not but this is what I get:
Depth Score Principal Variation
- --- ---
On Thu, Oct 2, 2008 at 3:48 PM, steve uurtamo <[EMAIL PROTECTED]> wrote:
> The networking issue is somewhat more serious.
> Not the actual network delay, but the mechanism
> that the boinc client software uses to process work requests
> and the interval at which people typically send
> back their r
It depends on your definition of real-time. A play-by-email target, such as the
Dragon Go Server is pretty flexible about scheduling moves. The project could
do what many people do and play several games in parallel. Each participating
computer would get a slice of multiple games to process in a
> But for grids (instead of clusters), the communication will become much much
> bigger - I'd like to study that carefully one day, I have no clear idea of
> what is possible.
>
> A trouble is that on grids (at least the ones I've seen) there are often
> faults. We'll have to be fault tolerant I g
The fault tolerance is not a serious problem, even
being tolerant against false result reporting isn't
too bad with a decent error-correcting coding
scheme for handing out the work.
The networking issue is somewhat more serious.
Not the actual network delay, but the mechanism
that the boinc client
Yes, various kinds of off-line (not in-game) processing could be done.
But nothing in a real-time game.
Cheers,
David
On 2, Oct 2008, at 10:48 AM, terry mcintyre wrote:
An @home network might be better for things such as creating opening
books, testing algorithms, etc.
___
without seki, B + W = 81, so B - W is always an odd number. 6.5 and 7.5
actually are different in case B - W = 7.
On Thu, Oct 2, 2008 at 3:16 PM, Antonin Lucas <[EMAIL PROTECTED]>wrote:
> On Thu, Oct 2, 2008 at 6:13 PM, Gian-Carlo Pascutto <[EMAIL PROTECTED]> wrote:
>
>>
>>
>> I'd have some prefe
For the use of fast networks:
yes, fast networks improve the results, in particular for 9x9, in my humble
opinion - however, you have already a good speed-up without
that, in particular for 19x19, and in particular if you have multiple cores
per node so that one core can take care of communications
On Thu, 2008-10-02 at 19:17 +0200, Michael Markefka wrote:
> So, when are we going to see distributed computing? [EMAIL PROTECTED],
> [EMAIL PROTECTED], [EMAIL PROTECTED] With Go engines that scale well to
> increased
> processing capacity, imagine facilitating a few thousand PCs to do the
> co
On Thu, Oct 2, 2008 at 6:13 PM, Gian-Carlo Pascutto <[EMAIL PROTECTED]> wrote:
>
>
> I'd have some preference for playing the decisive game with komi = 6.5,
> but apparently thats not possible on KGS. I think with komi = 7.5 white
> is scoring very high (too high?) in the top games.
>
Aren't 6.5
The @home systems work great for big problems that do not have time
constraints. Game playing is interactive and people expect reasonably
quick replies. The problem with @home computational models is that you
never know when the user will want their machine back, so you have the
problem of
>From what the Mogo team has said, the inter-processor communications
>requirements are high; they find it worthwhile to switch from ethernet to
>infiniband, or even to a higher speed infiniband. In short, Mogo seems to be
>bandwidth-limited.
An @home network might be better for things such as
Gian-Carlo Pascutto wrote:
> I'd have some preference for playing the decisive game
> with komi = 6.5, but apparently thats not possible on KGS.
But that should not be a problem, as long as the operators
do not believe in the final verdict of KGS.
> I think with komi = 7.5 white
> is scoring ve
So, when are we going to see distributed computing? [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED] With Go engines that scale well to increased
processing capacity, imagine facilitating a few thousand PCs to do the
computing. For good measure, [EMAIL PROTECTED] as about 800,000 nodes on
Mogo was allowed to use 800 cores, not more, and only for games against
humans.
We have no acces to so many cores for computer-computer games (if there were
only three teams involved,
we could :-) ).
For some games Huygens was unaivalable at all, and mogo played with much
weaker hardware (some quad
Huygens has 3328 cores, but I do not believe that Mogo
has run on more than 800, the number used for both
exhibition matches against Kim Myungwan.
Cheers,
David
On 2, Oct 2008, at 9:16 AM, Gian-Carlo Pascutto wrote:
Mogo runs on Huygens, which is 3328 cores...
On Thu, Oct 2, 2008 at 11:16 AM, Gian-Carlo Pascutto <[EMAIL PROTECTED]> wrote:
> Zach Wegner wrote:
>> On Wed, Oct 1, 2008 at 10:47 AM, Ian Osgood <[EMAIL PROTECTED]> wrote:
>>> Congratulations! Both for the gold, and for defeating Mogo. I never
>>> thought I'd see the day that the Go tournament
We've reached a point where 32, 40, or 64 cores is a modest research
investment. If we can find corporate sponsors, it should not be hard to gain
access to such hardware. Reading between the lines, I think some Microsoft
wunderkind may be backing Dave Fotland. More power to them! Now, here's hop
Zach Wegner wrote:
> On Wed, Oct 1, 2008 at 10:47 AM, Ian Osgood <[EMAIL PROTECTED]> wrote:
>> Congratulations! Both for the gold, and for defeating Mogo. I never
>> thought I'd see the day that the Go tournaments would bring heavier hardware
>> than the chess championship!
>
> You realize, of c
Ingo Althöfer wrote:
> What is done differently in Beijing?
In the players meeting the following was agreed instead:
2 games 30 minutes
if still draw
2 games 30 minutes
if still draw
toss for color, then
1 game 15 minutes
(If I remember correctly)
The idea is to avoid a medal being decide
On Wed, Oct 1, 2008 at 10:47 AM, Ian Osgood <[EMAIL PROTECTED]> wrote:
> Congratulations! Both for the gold, and for defeating Mogo. I never
> thought I'd see the day that the Go tournaments would bring heavier hardware
> than the chess championship!
You realize, of course, that Rybka played on
Gian-Carlo Pascutto wrote:
> the tiebreak is not yet finished! Place 2 and 3 are still undecided.
Hmm.
In the tournament rules
http://www.grappa.univ-lille3.fr/icga/event_info.php?id=20#Rules
it reads
> Tie-breaking:
> (a) if precisely two participants are tied for a medal place, precisely two
Darren Cook wrote:
>> Congratulations!
>
> Yes, well done David. I see Many Faces won even without getting the loss
> to Mogo reversed.
There was an investigation after my complaint, and the conclusion was this:
Mogo did score the game correctly, and Many Faces did not. The server
did not go to
Ingo Althöfer wrote:
> Rank 2 for MoGo after tiebreak against Leela.
Hello,
the tiebreak is not yet finished! Place 2 and 3 are still undecided.
--
GCP
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listin
I heard someone say that Yogo has a very strong 9x9 opening book prepared by
a professional. I was lucky enough to avoid playing them. MayFaces in 9x9
has no opening book at all other than "play the first move on 5-5".
david
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROT
All of ManyFaces' games are being played on kgs, using the ManyFaces1
account if you want to watch real time or get game records. The contest
continues tomorrow morning, china time.
David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Darren Cook
Sent:
The machines are in Redmond, at Microsoft. It's 4x 8-core XEON, with 16 GB
per core and 40 Gbps Inifinband networks. I'm going to try to use a bigger
machine tomorrow if the test results are good.
Cray just announced a "Personal Supercomputer" with 32 or 64 cores in a
small box.
David
-Ori
53 matches
Mail list logo
