>> ... play those 4 moves as if a single move
>
> I'd just like to point out that you shouldn't do this if there is a ko
> going on. ;-)
Yes, good point. It is possible to detect if you need a ko threat (the
illegal ko move is the move you want to play most), and in that case I
think I was wi
Hi,
I attempted to learn patterns from pro games, and use that to search
very deep (a bit like a MCTS playout, but I - foolishly - tried to do
just one best playout). One of the main concepts was treating local
sequences as a single move. A simple example is the 4-move hane-tsugi
sequence [1] in
> Chinese rules specify komi of 7.5. Japanese rules specify komi of 6.5.
> In the events I run, at least, I merely follow what the rules say,
> because I do not believe I have sufficient reason to override them.
Thanks Nick.
By the way, here is good explanation of why chinese rules don't use 6.5
Here is a simple optimization if someone want to give it a serious try:
When all 10 playouts for a move in the Meta-Playout either wins or
loses one could terminate the search early. If one need to be more
conservative one could terminate when the score is 0% or 100% N times
in a row.
Mag
What I tried was not a tree based version, so it's a very poor substitute.
I observed in private testing that even 10 playouts crushes 1 playout in a
simple non-tree based bot.So what I tried was doing recursive playouts -
instead of playing move randomly in the playouts each move in the play
I know I wasn't very clear with what exactly I tested, but I tested several
variations and could find nothing that worked. And I was ignoring the runtime
cost.
Michael Williams wrote:
I tried it in my previous engine, which while probably littered with
bugs, at least had the characteristic t
I tried it in my previous engine, which while probably littered with bugs, at least had the characteristic that more playouts lead to better play. This test
was extremely slow and produced a weaker bot. YYWV.
I'm 95% sure Don mentioned it on this list a couple of years ago, but I don't
know i
On Thursday 11 June 2009 14:50:14 Magnus Persson wrote:
> > Basically, you would run UCT as normal at the top level, and in the
> > playouts, use UCT with a small node limit.
>
> ...but this just cannot work it means a lot of search in order to
> update the tree once..
The results from the UCT-i
I'm not throwing in the towel J I had slow but steady progress from 20 kyu
in 1984 to 4 kyu in 2008, using my original code base, then a 2 stone jump
to 2 kyu with monte carlo. I'll continue to make slow steady progress,
probably until I die of old age.
David
From: computer-go-boun...@com
From: Magnus Persson
No this is not doable. Especially not in the endgame-subgame sense,
because there are no independent sub-games in 99% of a normal gogame.
This is the reason non-MCTS old school programs got stuck. Search must
be global. I am not saying
I've changed the Komi at GPW Cup from 7.5 to 6.5 after reading
Erik's suggestion on this list that it's more common in board games
that Black has some advantage.
Hideki
Darren Cook: <4a30f5fa.2060...@dcook.org>:
>> Announcement:
>> http://hp.vector.co.jp/authors/VA012620/cgf2009/cgf2009.html (
Nick Wedd: :
>In message <4a30d1df.9656%hideki_ka...@ybb.ne.jp>, Hideki Kato
> writes
>>Auch,
>
>You know German as well as English?
It should be "Ouch." ;-( But now I remember "auch" in German is
"also" in English, thanks. :-)
Ok, follwings are all of the regular Japanese computer Go tourname
No this is not doable. Especially not in the endgame-subgame sense,
because there are no independent sub-games in 99% of a normal gogame.
This is the reason non-MCTS old school programs got stuck. Search must
be global. I am not saying that local search cannot be helpful. It
just has to be
I invited him last year, thinking that restarting the computer
tournaments at the Congress might be interesting to him.
His answer was clear: He no longer does Computer Go.
Cheers,
David
On 11, Jun 2009, at 4:08 AM, Ingo Althöfer wrote:
Another 2 cents from me:
what about inviting good old
computer-go-boun...@computer-go.org wrote on 11-06-2009 23:00:56:
>
> I think one approach to scaling playouts is to subdivide the board,
> stipulate the outcome in a fixed part, and do "norman" playout in
> the interesting part. The trick is to do a reasonable subdivision
> in the first place.
In message <4a30d1df.9656%hideki_ka...@ybb.ne.jp>, Hideki Kato
writes
Auch,
You know German as well as English?
Japanese computer Go developers will have CGF Open computer
Go tournament on June 20th and 21st.
#CGF stands for Computer Go Forum (Japan).
#http://www.computer-go.jp/index.html
A
In message <4a30f5fa.2060...@dcook.org>, Darren Cook
writes
Announcement:
http://hp.vector.co.jp/authors/VA012620/cgf2009/cgf2009.html (in
Japanese)
I notice 9x9 is played at komi of 7.5. And the ICGA tournaments also
seem to be played at 7.5.
Yet I believe pro games are still played at 6.5, a
I think one approach to scaling playouts is to subdivide the board,
stipulate the outcome in a fixed part, and do "norman" playout in
the interesting part. The trick is to do a reasonable subdivision
in the first place. Imagine an advanced UCT model that conceptually
behaves like human evaluatio
Quoting Gian-Carlo Pascutto :
On Thursday 11 June 2009 13:16:42 Magnus Persson wrote:
Would this be a simple way of using many cores effectively?
I don't see what it has to do with multiprocessing.
Otherwise I cannot see how recursive UCT would be anything else than
an ineffective implement
> Announcement:
> http://hp.vector.co.jp/authors/VA012620/cgf2009/cgf2009.html (in
> Japanese)
I notice 9x9 is played at komi of 7.5. And the ICGA tournaments also
seem to be played at 7.5.
Yet I believe pro games are still played at 6.5, at least in Japan [1].
FWIW, my own study suggests correc
On Thursday 11 June 2009 13:16:42 Magnus Persson wrote:
> Would this be a simple way of using many cores effectively?
I don't see what it has to do with multiprocessing.
> Otherwise I cannot see how recursive UCT would be anything else than
> an ineffective implementation of UCT. Unless it provid
I know what Moore actually said and what is perceived as Moore's law are two
different things. But it's pretty much the case that performance has
doubled every couple of years.
Nobody really believes that Moore's law will continue although it's pretty
amazing that its demise keeps getting predic
I very strongly suspsect that Many Faces, Mogo, Crazy Stone and others are
heavily optimized to play well on exactly the hardware we have at the
moment.
There is the huge problem that you cannot easily test scalability because
you cannot produce the thousands of game needed to get accurate numbers
Would this be a simple way of using many cores effectively?
Otherwise I cannot see how recursive UCT would be anything else than
an ineffective implementation of UCT. Unless it provides some
information that could be used more effectively than with normal search.
In order to do so the playo
Another 2 cents from me:
what about inviting good old Bruce Wilcox for
a show event against computer(s)?
With him you would get all in one:
* strong amateur
* author of (old) go program
* author of one of the best go books ever
Ingo.
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Je
Auch,
Japanese computer Go developers will have CGF Open computer
Go tournament on June 20th and 21st.
#CGF stands for Computer Go Forum (Japan).
#http://www.computer-go.jp/index.html
Announcement:
http://hp.vector.co.jp/authors/VA012620/cgf2009/cgf2009.html (in
Japanese)
Entrants:
http://hp
On Wednesday 10 June 2009 18:48:55 Martin Mueller wrote:
> Currently, we try to sidestep this fundamental problem by replacing
> local search with local knowledge, such as patterns. But that does not
> fully use the power of search.
So, has anyone tried recursive UCT (using UCT again in the playo
On Wednesday 10 June 2009 22:15:22 Ian Osgood wrote:
> We have evidence against going this low: Rybka and several other
> modern engines were ported to the dedicated computers Resurrection
> (203 MHz StrongArm) and Revelation (500 MHz XScale). Rybka's rating
> in the SSDF pool on these platforms
In my humble opinion, we need a change in the algorithm. The numbers are
misleading - 95% of win of
MoGo on 32 nodes against MoGo on 1 node (this is a real number for 19x19)
certainly means that the
parallel version is stronger than the sequential version, but not "much"
better, far less than what
Hardware has a huge effect on go strength, but mainly by enabling better
algorithms. MCTS would have been impossible on the 640 KB, 24 MHz, 80286 I
used to develop Many Faces of go.
I think you would agree with me when I say that the stronger programs five
years from now will gain that strengt
In all my test with Valkyria it is absolutely clear that strength
improves with more computational resources. On 19x19 it is even more so.
But I do think most programs has a wall in front of the mountain. And
this is *bugs*. Consider what would happen if a line of code in a
program resigns
First, Moore said that density would double every 18 months or so. He did
not say performance would double. Second, lately it's harder to double so
it is more like two years per doubling. Third, Moore's law won't continue
for 40 more years. Trust me, I'm CTO at a semiconductor company J
Ver
32 matches
Mail list logo
