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
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
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 faster,
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
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
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).
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:
-
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
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
christ...@modeltwozero.com mailto:christ...@modeltwozero.com wrote:
Mark,
let me try to add some more context
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 this is the lightest
possible playout. The raw numbers
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
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
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
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
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 dailey@gmail.com:
On Sun,
-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
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 than
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
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 Nentwich
christ...@modeltwozero.com mailto:christ...@modeltwozero.com wrote
/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/
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
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
|- - - - - - -
|. * * 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
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
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
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
christ...@modeltwozero.com mailto:christ...@modeltwozero.com wrote:
All,
FYI, the Python version of the CGOS client has moved
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:
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
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
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
/
___
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
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
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
, but I will discuss it with you
when the time comes.
- Don
On Wed, Jun 10, 2009 at 2:23 PM, Christian Nentwich
christ...@modeltwozero.com mailto:christ...@modeltwozero.com wrote:
All,
I have released an alternative client for CGOS, written in Python.
I had some features
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
/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/
.
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/
/
___
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 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
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
40 matches
Mail list logo
