Hi all,
I've been looking through the archives trying to find out if anybody had
published information on the following during uniform random playouts
and/or real games:
- Frequency of string merges
- Frequency of placing stones in empty space
- Average length of strings, etc.
I noticed th
er-go.org <mailto: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/
--
Christian Nentwich
Director, Model Two Zero Ltd.
+44
-go mailing list
computer-go@computer-go.org <mailto:computer-go@computer-go.org>
http://www.computer-go.org/mailman/listinfo/computer-go/
_______
computer-go mailing list
computer-go@computer-go.org
http://ww
This time management business is quite interesting. I looked into this
in some detail a while ago and came up with something I think is
reasonable for 9x9. I'd love to hear what you all think about it.
My algorithm relies on two key parameters: the time left (which is
either reported by a se
Doh. And just because typing mathematics in a mail from handwritten
notes had to go wrong: the initial formula was time(current move) / x ^
(1 / n), not 1 / x ^ (1 / n), otherwise it obviously cannot be solved
for the time in the second step.
Christian
On 23/05/2009 21:26, Christian
n May 23, 2009, at 4:26 PM, Christian Nentwich
mailto:christ...@modeltwozero.com>> wrote:
This time management business is quite interesting. I looked into
this in some detail a while ago and came up with something I think is
reasonable for 9x9. I'd love to hear what you all think
ought to be fixed.
Nick
--
Christian Nentwich
Director, Model Two Zero Ltd.
+44-(0)7747-061302
http://www.modeltwozero.com
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Christian Nentwich
Director, Model Two Zero Ltd.
+44-(0)7747-061302
http://www.modeltwozero.com
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
This is kind of interesting. Is anybody measuring their playout
performance in real-time at the moment and performing this sort of
computation, to check if overtaking the leading move is mathematically
impossible?
It's interesting with UCT because of the interplay between the time
manageme
All,
I have released an alternative client for CGOS, written in Python. I had
some features in there that are useful to me, and I thought maybe others
could benefit from it.
Some key interesting features:
- GTP extensions that tell your engine who the opponent is, and what
the result was (
mmunicated, but I will discuss it with you
when the time comes.
- Don
On Wed, Jun 10, 2009 at 2:23 PM, Christian Nentwich
mailto:christ...@modeltwozero.com>> wrote:
All,
I have released an alternative client for CGOS, written in Python.
I had some features in there that
Terry,
I don't think the part of the argument looking at hardware is sound. You
are assuming that computing power is going to continue to provide a
linear strength increase with every doubling. I think the argument being
made by a few of the previous posters is that the strength curve is
show
stinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Christian Nentwich
Director, Model Two Zero Ltd.
+44-(0)7747-061302
http://www.modeltwozero.com
___
computer-go mailin
Lukasz,
your client doesn't seem to be displaying all the info for some reason:
" -c specified name of config file - this is MANDATORY
-k sepcifies a file to create which will stop client after current game
-p specifies which player plays first game
-s display a sample configuration file to stdo
Are you asking about in-memory storage, or on disk?
On disk, you probably want to make sure that it's as easy as possible to
maintain - up to your taste. Some people like a single SGF file with
variations. You can do mirrorring and transpositions when you load the book.
Christian
Willemien
All,
FYI, the Python version of the CGOS client has moved into the main CGOS
sourceforge area:
http://cgos.sourceforge.net/client-python/
There is also a new release (0.3.0) out that supports multiple engines.
Christian
___
computer-go mailing list
NoGo
e1 cgosNoGo 0.1 alpha - Java engine client for Nogo
e1 cgosPython 0.1 beta
e1 cgosPython 0.2 beta
e1 cgosPython 0.3.0 beta
e1 joe
e1 myCtest
e1 test client
e1 testing
v1 "0.1 NaruGo client for CGOS."
v1 NaruGoTest
- Don
On Tue, Jun 23, 2009 at 8:20 AM, Christian Nentwich
mailto:chr
Peter,
I tried to reproduce this, so I gave this a whirl and the win rate
against UCB-Tuned1 with first move priority of 1.1 (like Mogo) was only
33%. That was using uniform random playouts.
What was the playout policy you used for this?
Christian
On 18/06/2009 21:04, Peter Drake wrote:
An
And unrelated:
- I've sometimes wanted to see who is currently playing on the
server. Will this be possible (e.g. through a web pages that gets
updated every few minutes)?
The web page will be in PHP, so when you refresh the web page you
will get the exact and current state
Don,
you might have your work cut out if you try to control inflation
directly, that can turn into a black art very quickly. Multiple anchors
would be preferable. An offline, X * 1000 game playoff between gnugo and
another candidate anchor would be enough to fix their rating difference.
If th
play with full strength programs.
I am looking forward to the new server because I think everyone
would/should be eager to login to it.
Magnus
Quoting Don Dailey :
2009/6/24 Christian Nentwich
Don,
you might have your work cut out if you try to control inflation
directly,
that can turn
Darren,
this sounds like a good insight, but only if a very large number of
playouts have been performed. By contrast, the original poster writes:
But in the opening, where the scoring
leaves are 300 moves away from the root, surely a putative half point
win doesn't translate to a significant
|- - - - - - -
|. * * o . . .
|* . * o * . *
|o . o o * . .
|o * o . * . .
|o o o * . . .
|. * * * . . .
|. . . . . . .
|. * . . . . .
Black to play and kill :)
Christian
On 01/07/2009 17:41, Magnus Persson wrote:
In this case one needs to check that after the two stones are captured
the cap
Hi all,
do any of you have performance figures for multi-processor AMD
(opteron/shanghai) systems with your engines? Any single-processor?
There's a good offer here on AMD based servers to get the second
processor for free, so I am thinking of pouncing on it. I'm curious
about how the better
st
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Christian Nentwich
Director, Model Two Zero Ltd.
+44-(0)7747-061302
http://www.modeltwozero.com
___
computer-go mailing list
computer-go@computer-go.org
http://w
>The problem I think is to find a good tradeoff between heavyness and
speed. In my test with Valkyria vs Fuego, Valkyria is superior when the
number of playouts are the same. But >Fuego can play 5 times more
playouts per second on the hardware that results in Fuego being slightly
stronger tha
Darren Cook wrote:
seems to me that making algorithms heavier and then demonstrating that
they are stronger with the same number of playouts misses the point -
why would one not run an experiment under the same time conditions instead?
* The heavier algorithm might be unoptimized;
That
lexities, maybe
look at average cases too. I don't see a lot of people trying to "prove"
that their algorithms are improvements in Go, because it is generally
too complex; so evidence is all we get.
Christian
Don Dailey wrote:
On Tue, Jul 7, 2009 at 6:31 AM, Christian Nent
ailman/listinfo/computer-go/
--
Christian Nentwich
Director, Model Two Zero Ltd.
+44-(0)7747-061302
http://www.modeltwozero.com
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Ingo,
are you sure you already want to bet on one particular technique? :)
I don't believe a score optimisation algorithm like UCT works all that
well when behind. I am pretty sure that human players do *not* choose
between the top three moves if their values are 40%, 39% and 38%. They
will start
Don, others,
are there publications about this? If people have tried it out, are
there any threads on this list that somebody remembers where results
are posted? I have not been able to find any. It would be interesting
to see.
Christian
2009/7/12 Don Dailey :
>
>
> On Sun, Jul 12, 2009 at 8:
Brian,
reading this ascii can be difficult, so I might be missing something,
but why would white play F5 after E1 in your primary variation, instead
of playing atari at B2 to prevent the seki? Would this lose on points?
(Couldn't quite tell without knowing the prisoner count)
I don't see how
This is probably the best route. Either this, or get rid of the rule.
This rule cannot be shown to be correct in general, it may work for most
life and death problems, but can be wrong in semeai. You may get a nice
ELO increase, but you are still actively building a wrong rule into the
progra
I suppose it is worth bringing this new variant to people's attention.
What will become of it, who knows, it may fade quickly:
http://www.godiscussions.com/forum/showthread.php?t=7176
Christian
___
computer-go mailing list
computer-go@computer-go.or
I did quite a bit of testing earlier this year on running playout
algorithms on GPUs. Unfortunately, I am too busy to write up a tech
report on it, but I finally brought myself to take the time to write
this e-mail at least. See bottom for conclusions.
For performance testing, I used my CPU
nctions between
those few board moves by offloading the heavy lifting.
s.
2009/9/9:
Interesting stuff. Thanks for reporting your results.
- Dave Hillis
-----Original Message-
From: Christian Nentwich
To: computer-go
Sent: Wed, Sep 9, 2009 11:54 am
Subject: [computer-go] CUDA and GPU P
Mark,
let me try to add some more context to answer your questions. When I say
in my conclusion that "it's not worth it", I mean it's not worth using
the GPU to run playout algorithms of the sort that are in use today.
There may be many other algorithms that form part of Go engines where
the
ation is roughly 7x as fast as the bitboard
implementation I presented just a few weeks back, and also outperforms
libEgo by about a factor of two.
René
On Wed, Sep 9, 2009 at 2:57 PM, Christian Nentwich
mailto:christ...@modeltwozero.com>> wrote:
Mark,
let me try to add some m
order of
magnitude faster by a devious implementation that minimizes branching
there might be something to it using the two-staged playout approach.
And since it doesn't burden the CPU (much) you basically get it free.
Mark
On Wed, Sep 9, 2009 at 11:57 AM, Christian Nentwich
wrote:
approach could
shine more, since I can easily match patterns everywhere on the board
at once. Still, I wonder if it will become at least on par with good
CPU implementations.
On Wed, Sep 09, 2009 at 04:54:23PM +0100, Christian Nentwich wrote:
In other words: no tree search is involved, and t
Brian,
this is interesting.
The sequence is as interesting as the superko, really, because it's the
sort of strange sequence that would only occur to monte carlo programs.
When black plays B9, a human white player would answer H4. This gives
the highest win. If he's feeling obliging, he might
Go has been played long enough, and the proposed "great wall" opening is
simple enough, that is should be more than valid to argue that "if it
was a good opening, it would be played more often".
Here are some openings that have been found to lead to high winning
percentages in real games:
Darren,
these articles are still somewhat short on detail, so it's hard to tell.
A lot of the "new features" listed there won't have any impact on the
suitability of the GPU for Go, because they do not change the method of
computation (e.g. doubling floating point precision is irrelevant).
H
rformance of playout algorithms on
the architecture will shoot up.
I only skimmed it very lightly, but page 15 discusses memory and page 16
shows how this gives big speedups for radix sort and fluid simulations.
Darren
--
Christian Nentwich
Director, Model Two Zero Ltd.
+44
I suspect I am in your camp, Mark, though obviously it would be nice if
we had measurements on this instead of conjectures.
I will offer some anecdotal evidence concerning humans playing other
humans, from club and tournament playing experience: you will find that
shorter time limits amplify
Steve,
I was one of the people who posted in the debate - I implemented light
playouts on CUDA for testing purposes, with one thread per playout
(rather than one per intersection).
I think one of the main things that I am curious about, and I don't
think I am the only one, is whether texture
On Tue, Dec 08, 2009 at 09:30:47PM -0500, Eric Boesch wrote:
> > You can mathematically prove the two systems are almost the same, so
> > there's no need to test.
>
> Yes, this was my line of thought, but I wasn't sure if I'm not missing
> anything...
>
>
If you ever decide to test which is fast
All,
the CUDA light playout code I wrote earlier this year and posted about in
this list is lying around dead on my hard disk, and I am not looking to take
it anywhere.It's certainly not production code, as it was written as an
experiment, but I think there is still value in releasing it.
I don't
Steve,
I wouldagree with you that writing a good score estimator is extremely
difficult, probably as difficult as writing a computer player.
However, your argument of equivalence (if that is how I understand it) does
not follow. Just because you can score any position does not mean you can
theref
49 matches
Mail list logo
