hi,
Thanks Dave Hillis for this quick response. (And by the way, thanks to Remy
Coulomb for a previous response he made a while ago. I just though that post
containing only thanks would be noise to most people there ...)
To Don and Christoph : I reallize that i was probably not as clear as i
On Wed, 2008-10-08 at 14:35 +0200, Denis fidaali wrote:
hi,
Thanks Dave Hillis for this quick response. (And by the way, thanks to Remy
Coulomb for a previous response he made a while ago. I just though that post
containing only thanks would be noise to most people there ...)
To Don and
On 7-okt-08, at 21:40, Don Dailey wrote:
On Wed, 2008-10-08 at 08:25 +0900, Darren Cook wrote:
And now I look at the ATS implementation of binary-trees, it is using
threads, while the C++ version is single-threaded.
Lots of apples and oranges comparisons here :-).
And there is no single
Christoph,
Do you use all-moves-as-first? If not, this data seems to match mine
very well. The upper bound seems to be around 1300 ELO give or take a
few ELO.Ike seems to be around 1300 ELO with 10k play-outs but they
are all-as-first.I'll let it run a few days.
- Don
On Tue,
Looking superficially...
The game length appears in the right ballpark. I seem to remember
110-112 moves, depending on how passed are counted.
20k playouts/core/sec seems reasonable for lightly optimized.
The center bias also looks correct.
The win rates don't look right to me. 7.5 Komi
On Fri, Oct 3, 2008 at 2:33 PM, Don Dailey [EMAIL PROTECTED] wrote:
I had heard somewhere that there are some who believe 8.0 is the right
komi for 9x9 Chinese. I personally believed for a long time it was 7.0
based on statistical data of games.However that can be misleading.
Do you
I put up my old simple MC program on CGOS 9x9 as a reference bot.
It is called Ike and IkeJr, Ike does 1 playouts and IkeJr does
1000.
Here is how the play-outs work:
1. play uniformly random simulations.
2. Eye rule as described.
3. Play until no non-eye moves left, then pass.
On Fri, Oct 3, 2008 at 1:23 AM, Gunnar Farnebäck [EMAIL PROTECTED] wrote:
At http://trac.gnugo.org/6x6.sgf you can find an ongoing analysis of
6x6.
Nice! The main line looks correct.
It even has an interesting 59-ply deep variation which I don't
remember seeing before.
Erik
On Wed, 2008-10-08 at 08:25 +0900, Darren Cook wrote:
And now I look at the ATS implementation of binary-trees, it is
using
threads, while the C++ version is single-threaded.
Lots of apples and oranges comparisons here :-)
If you don't want to see quad-core look at the Q6600 measurements for
On Wed, 8 Oct 2008, Don Dailey wrote:
Christoph,
Do you use all-moves-as-first? If not, this data seems to match mine
very well. The upper bound seems to be around 1300 ELO give or take a
few ELO.Ike seems to be around 1300 ELO with 10k play-outs but they
are all-as-first.I'll let it
It was 4x 8-cores.
-Original Message-
From: [EMAIL PROTECTED] [mailto:computer-go-
[EMAIL PROTECTED] On Behalf Of terry mcintyre
Sent: Wednesday, October 01, 2008 9:23 AM
To: computer-go
Subject: Re: [computer-go] Congratulations to David Fotland!
I'm curious -- was this an 8 x
I checked my notes. For Light playouts
---
average game length 111 (including final 2 passes)
not counting passes 107
---
When these numbers match, it's a pretty strong sign that the implementation is
correct (particularly the eye rule).
- Dave Hillis
-Original Message-
From: Jason
On Tue, 2008-10-07 at 14:04 -0700, Christoph Birk wrote:
name#light_simulations ELO
myCtest-10k 1 1000
myCtest-50k 5 1300
Ok, it looks like 1300 is a rough upper bound. At the moment I am
getting 1335 with 10,000 sims doing
On Wed, 2008-10-08 at 15:18 +0200, Erik van der Werf wrote:
On Fri, Oct 3, 2008 at 2:33 PM, Don Dailey [EMAIL PROTECTED] wrote:
I had heard somewhere that there are some who believe 8.0 is the right
komi for 9x9 Chinese. I personally believed for a long time it was 7.0
based on
On Wed, 8 Oct 2008, Don Dailey wrote:
much more common.There were just a few games that used 6.5 komi
because when I first started CGOS I had set 6.5 by mistake but I think
that was just for a few hours at most. The vast majority of these are
7.5 komi games:
After all this discussion
Don Dailey wrote:
On Wed, 2008-10-08 at 15:18 +0200, Erik van der Werf wrote:
On Fri, Oct 3, 2008 at 2:33 PM, Don Dailey [EMAIL PROTECTED] wrote:
I had heard somewhere that there are some who believe 8.0 is the right
komi for 9x9 Chinese. I personally believed for a long time it
was 7.0
On Wed, 8 Oct 2008, Denis fidaali wrote:
Now, i wanted to make sure that my implementation had any chances to be
correct. So i though I'd post the characteristic statistical values that
i get out of it. Indeed i though it could benefits others later on, in
particular if someone could
On Wed, 8 Oct 2008, Denis fidaali wrote:
To Don and Christoph : I reallize that i was probably not as clear as i though
i was.
I have built up a light simulator. There are no tree involved. It is
only choosing a move with equiprobabilty from the set of empty points on
the board.
That's
On Wed, 2008-10-08 at 11:47 -0700, Christoph Birk wrote:
On Wed, 8 Oct 2008, Don Dailey wrote:
much more common.There were just a few games that used 6.5 komi
because when I first started CGOS I had set 6.5 by mistake but I think
that was just for a few hours at most. The vast
On Wed, 2008-10-08 at 20:56 +0200, Gunnar Farnebäck wrote:
Don Dailey wrote:
On Wed, 2008-10-08 at 15:18 +0200, Erik van der Werf wrote:
On Fri, Oct 3, 2008 at 2:33 PM, Don Dailey [EMAIL PROTECTED] wrote:
I had heard somewhere that there are some who believe 8.0 is the right
komi for
On Wed, 8 Oct 2008, Don Dailey wrote:
On Wed, 2008-10-08 at 11:47 -0700, Christoph Birk wrote:
On Wed, 8 Oct 2008, Don Dailey wrote:
much more common.There were just a few games that used 6.5 komi
because when I first started CGOS I had set 6.5 by mistake but I think
that was just for a
I agree that the komi should not be changed unless there is a very
compelling reason. My engine would have to be entirely recreated to
support a different komi and I only want to maintain one engine for
each boardsize.
- George
On Wed, Oct 8, 2008 at 3:46 PM, Don Dailey [EMAIL PROTECTED] wrote:
From: Gunnar Farnebäck [EMAIL PROTECTED]
I suspect that quite a few of the odd scores are not due to the
presence of seki with an odd number of neutral points but are caused
by uncaptured dead stones.
Which program (or programs) is most reliable at determining life-and-death and
seki
On Wed, Oct 8, 2008 at 9:46 PM, Don Dailey [EMAIL PROTECTED] wrote:
On Wed, 2008-10-08 at 11:47 -0700, Christoph Birk wrote:
On Wed, 8 Oct 2008, Don Dailey wrote:
much more common.There were just a few games that used 6.5 komi
because when I first started CGOS I had set 6.5 by mistake
As programs become stronger the advantage for one side with fractional
komi will inevitably become totally unbalanced. At some point we will
approach 100% and then I rather have that go to the first player. The
only fair alternative is to use integer komi.
Or a bigger board.
On Wed, Oct 8, 2008 at 3:46 PM, Don Dailey [EMAIL PROTECTED] wrote:
Is there any way to prove that with best play the game cannot end in
seki?
It seems like most reasonable sequences in Chinese rules 4x4 go end in
a whole-board seki. I would expect that for 19x19 go, some avenues of
best play
On Wed, 2008-10-08 at 22:43 +0200, Erik van der Werf wrote:
The only reason I would favor one over the other
is if it turned out that in practical play the games ended up
closer.
For instance if black won a 53% at 6.5 komi and white wins 51% at
7.5
komi, I would favor 7.5 because it kept
On Wed, 2008-10-08 at 22:43 +0200, Erik van der Werf wrote:
I believe 6.5 would give black a bigger advantage than 7.5 gives
white in practical play.
This may be true for your CGOS games.
I did a quick check on CGOS 9x9 and white wins 52.05%
I did not filter based on strength, this is
ATS does the binary-trees test 6.2 times quicker than C++ but 2.7 times
slower on k-nucleotide (which seems to be about making hash tables):
Prompted by Isaac, I found the single-core benchmarks (change the u64q
to u32 in the URLs I posted before to get them, or start at
Let me check CGOS statistics based on relatively evenly match opponents
and I will filter out players that are pretty weak. Then I'll present
the data.
CGOS is not really a democracy, but I do care about the wishes of the
program authors. So after I show some data, if it's highly in favor
I suggest you filter all but the very strongest players, to get a more
accurate komi, from the strongest games.
David
-Original Message-
From: [EMAIL PROTECTED] [mailto:computer-go-
[EMAIL PROTECTED] On Behalf Of Don Dailey
Sent: Wednesday, October 08, 2008 7:03 PM
To: Erik van der
On Wed, 2008-10-08 at 19:11 -0700, David Fotland wrote:
I suggest you filter all but the very strongest players, to get a more
accurate komi, from the strongest games.
There is a trade-off here of course. If you only look at a small
sample you can have a lot of error.
I'll have 2
I'm not sure if it's wise to ignore games lost on time. For a MCTS
program it makes sense to adjust the time taken for the move based on
its perceived chance of winning. But that means a program is more
likely to lose on time because it's losing anyway, and that judgement
involves the
On Wed, 2008-10-08 at 23:35 -0300, Mark Boon wrote:
I'm not sure if it's wise to ignore games lost on time. For a MCTS
program it makes sense to adjust the time taken for the move based on
its perceived chance of winning. But that means a program is more
likely to lose on time because it's
Ok, I'm doing the komi study. I hope this data formats properly on
your email clients.
I am not including the first day or two of games because I remember
that I started out with 6.5 komi but I think that only lasted a few
hours.
I'm including ALL games unless they ended with an illegal move.
Hello all,
in other games (on other servers) games start with a
komi-bidding procedure.
Only when both sides propose the same value for komi,
colors are given by chance.
In my eyes, for Go it would be useful also to allow
integral komi (7.0 for 9x9, for instance).
Ingo.
--
GMX Kostenlose
Integer komi has a problem for many MCTS implementations, since a playout
only returns win or loss. This would require playouts to also return drawn.
My playouts work this way. I know Erik's can return draw. I dont know
about mogo or leela.
Davdi
-Original Message-
From: [EMAIL
37 matches
Mail list logo
