Hi Michael
Another cost is undo. Superko requires undo, unless
you want store a hash value with each chain of stones.
I am not sure exactly what undo costs, but lets say
5% to 10%.
Well, every implementation is different. In its slowest
mode, my board stores information about neighbor stones
Mark Boon wrote:
I'm fairly new on the subject of Monte Carlo and am in the process of
catching up on reading, so I hope you guys have some patience with me
while I get into this and ask a lot of questions. I got side-tracked
away from computer-Go programming for quite a while for various
Self-atari is never referred to as suicide. Let's not start now. But you're right self-atari in the playouts is a more interesting topic. You have to allow
it sometimes because it is the correct move sometimes.
John Fan wrote:
A question on this topic. When we discuss about suicide, are we
So it's possible to create a triple-ko repetition, take that move sequence
and find
a non-triple-ko situation that uses the exact same repeated move sequence ?
I am afraid I don't follow. Please rephrase.
In my words: you have a sequence of moves (M0) leading,
to a certain position (P0).
On 18-jan-08, at 12:47, Don Dailey wrote:
I recently read an interesting blog on this, where it was claimed
that
early optimization SHOULD be done when performance is actually a
consideration (and sometimes it isn't.) The idea is that if ignore
performance consideration early, you
A question on this topic. When we discuss about suicide, are we referring to
the real suicide, or self-atari? I think in some discussions it is referring
to the real suicide. In other discussions, seems to be referring to
self-atarai.
If we are talking about real suicide, I do not see any point
So I wouldn't be surprised at all if at some point you'll see a
marriage of the best ideas of traditional Go programs and Monte-
Carlo / UCT. In fact, this is most likely already happening as these
Monte-Carlo programs use algorithms / ideas from the traditional
programs for tactics,
Heikki Levanto wrote:
On Thu, Jan 17, 2008 at 10:36:09PM -0500, Michael Williams wrote:
I have not tried it myself, but I'm guessing it will not improve your
engine. The cost of testing for simple ko is negligible and allowing it
will probably prolong the playouts.
I am not far enough with
It is two years and six months since I chose the format that we use for
the monthly bot tournaments on KGS. Since then, things have changed:
UCT has been invented, processing power has increased, pondering has
been implemented in more programs, and CGOS is running. I get
occasional requests
John Fan wrote:
If we are talking about real suicide, I do not see any point to allow
the real suicide in the play out. What would be the gain if we allow the
real suicide in the play out.
The answer to this question has been given at least 3 times:
Speed.
It can take time to disallow a
I'm fairly new on the subject of Monte Carlo and am in the process of
catching up on reading, so I hope you guys have some patience with me
while I get into this and ask a lot of questions. I got side-tracked
away from computer-Go programming for quite a while for various
reasons but have
Hi,
My vote would be to keep everything like it is. Maybe use round robin
when the number of participants is close to the number of planned
rounds. Also, don't hesitate to make the time control shorter if it
would be necessary to fit enough rounds within a reasonable time, so we
can play
I'm sorry but I have no fixed global ip (my pcs are at my home, not
at univ). But I strongly believe 32 bit applications can run on 64
bit OS.
I will try to run currently running four bots and your clients
as many as possible simultaneously because I've just built up an
additional 2 core pc.
Jason House wrote:
On Jan 18, 2008 11:30 AM, Raymond Wold wrote:
With simple ko checking, around 3% of games ended in infinite loop with
double ko.
Double ko's should not have an infinite loop. black takes ko A. White
takes ko B. Black can't retake ko B, so must fill ko A. White
Hello All,
First, Thanks to Nick for doing these tournaments and for asking what
we would like.
Sticking with most of the replies I have seen so far, I will send my
votes on the form directly to Nick, but will comment here on a few
points.
First, I am wondering about the 2-out-of-3
The new scalability study is in progress. It will be very slow going,
only a few games a day can be played but we are trying to get more
computers utilized.
I will update the data a few times a day for all to see. This includes
a crosstable and ratings graphs. The games will be made
On Jan 18, 2008 11:30 AM, Raymond Wold [EMAIL PROTECTED] wrote:
My own experience when experimenting with random playouts were that
without ko checking at all, around 30% of games ended in infinite loop
with both sides having one (non-eye-filling) move possible, to retake
the ko.
My
An alternative to matching board hashes is to test for repeated move
sequences.
No. repeated position != repeated sequence.
Since one stone is added to the board with each move,
a repetition can only exist between two moves if exactly that number
of stones was captured inbetween (+- pass
On 18-jan-08, at 12:01, Gian-Carlo Pascutto wrote:
But the speed of the random playout becoms less and less important
with heavy playouts.
This I don't understand at all. The improvement curve for being
faster isn't different with heavy than with light playouts.
I see I didn't word this
On Fri, 2008-01-18 at 20:31 -0500, Don Dailey wrote:
Although it's not on the graph itself, Gnugo-3.7.11 level 10 is set to
be 1800.0 ELO.
On the web page it says you are using --min-level 8 --max-level 8.
Each data point in the x axis represent a doubling in power. There are
13 doublings
On Jan 18, 2008, at 9:41 AM, Nick Wedd wrote:
The Formal/Open restriction was created to encourage commercial
programs to compete. These programs' authors were wary of entering
them in events in which they might have to play a whole bunch of
GNU Go versions, so the Formal division was set
I wish I had named the weakest players _00 instead of _01 and expressed
everything as you are suggesting, it would indeed be clearer.
I could actually fix this by reprogramming the scripts without changing
the running programs. If I get a burst of energy perhaps ...
The tarball is slightly
An alternative to matching board hashes is to test for repeated move sequences. You need a separate test for each sequence length, but the most common one
should be the shortest one.
Heikki Levanto wrote:
On Thu, Jan 17, 2008 at 10:36:09PM -0500, Michael Williams wrote:
I have not tried it
So I wouldn't be surprised at all if at some point you'll see a
marriage of the best ideas of traditional Go programs and Monte-Carlo /
UCT. In fact, this is most likely already happening as these
Monte-Carlo programs use algorithms / ideas from the traditional
programs for tactics,
Mark Boon wrote:
On 18-jan-08, at 12:01, Gian-Carlo Pascutto wrote:
But the speed of the random playout becoms less and less
important with heavy playouts.
This I don't understand at all. The improvement curve for being
faster isn't different with heavy than with light playouts.
I see I
Jeff Nowakowski wrote:
On Fri, 2008-01-18 at 20:31 -0500, Don Dailey wrote:
Although it's not on the graph itself, Gnugo-3.7.11 level 10 is set to
be 1800.0 ELO.
On the web page it says you are using --min-level 8 --max-level 8.
I realized after I started the study that I was
26 matches
Mail list logo
