Hi Hiroshi,
I would interpret your results as K=600 is to big,
Detlef
P.s. this would be consistent with my results
Am Sonntag, den 23.11.2014, 10:20 +0900 schrieb Hiroshi Yamashita:
Hi Erik,
Perhaps the interesting part is in fading out more slowly than with
ordinary priors (i.e., by
Hi, I use this chanel:
kgs has a new client kgsGtp-3.5.20, but I get AM FEINSTEN: Got
successful response to command time_settings 900 30 10: =
java.lang.NullPointerException
at com.gokgs.client.gtp.y.a(kgsgtp:22)
at com.gokgs.client.gtp.z.a(kgsgtp:58)
at
i7-5960x at 3.5GHz he said
Am Sonntag, den 05.10.2014, 19:48 +0200 schrieb Erik van der Werf:
Well, not a laptop, but a '6-core desktop' can still be quite fast...
E.g., the 48-core amd machine I often use is typically only around 2.5
times faster than a stock i7 3930k (and then I haven't
Sorry 5930x
Am Sonntag, den 05.10.2014, 19:48 +0200 schrieb Erik van der Werf:
Well, not a laptop, but a '6-core desktop' can still be quite fast...
E.g., the 48-core amd machine I often use is typically only around 2.5
times faster than a stock i7 3930k (and then I haven't even considered
Hi,
I try to find a way to measure the drift of the probability of a node. I
am not looking for a heuristic like compare the last 1000 playouts with
the probability of all playouts but something more general.
I found some articles over Drift Analysis, which are used in a
different way, but may
Hi,
I am writing a little paper on a new backup operator for MCTS. Now I
just realized, that most (nearly all) computer go related papers are
published in conference proceedings.
As a high school teacher I have no possibility to take part at
conferences:(
Do you think there are reasonable
Hi,
I am really missing CGOS :(
I had a short look at the sourceforge project page. If I remember
correctly cgos.computergo.org was running fine (not at the moment)
without rating.
If I remember correctly cgos.boardspace.org used fatman go program to
fix the 1800 ELO in 9x9. In the cgos server
This was also my impression. I usually use spec int_rate as a measure.
Nicego has a little stronger hardware than AyaMC (but the mpi code is
still not working perfectly)
MCark should be little stronger than Fuego9, if I understand correctly 2
cpus E5-2450 (16cores)
but the more experienced
oakfoam too, but I remember it was different before large patterns and
other features.
My working hypothesis is: if one thread on a core can wait for memory
read the other thread can work (as far as I remember two HTs share the
same integer and floating point units e.g.).
If there are no bottle
Thanks Nick,
so proude, that NiceGo was worth of discussions:)
In fact in the first game you discussed NiceGo played move 40 against
Aya and took it from the Pro Opening Book (linked from the fuego page).
Therefore we should check which pro invented it:)
Thanks a lot
Detlef
Am Donnerstag, den
Hi,
as a result of my oakfoam scaling tests I had a look at our progressive
bias impementation.
I recognized, that the playing strength is quite sensitive to the exact
way of progressive bias. I looked into pachi and the Progressive
Strategies for Monte-Carlo Tree Search paper.
I could not
Thanks a lot for the replay, I did not find this old discussion.
move probability is gamma/(sum of all gammas), so my formula would be
equivalent to using
log(probability)
(as 1/(sum of all gammas) results in a additive constant after log)
so the question is:
why should I add
winrate +
Am Samstag, den 21.12.2013, 13:10 +0100 schrieb Petr Baudis:
Hi!
On Sat, Dec 21, 2013 at 08:18:50AM +0100, Detlef Schmicker wrote:
Thanks a lot for sharing so much information. I am checking all your
suggestions :)
I wonder, if the biggest difference between fuego, oakfoam compared
19x19 results fuego against pachi with pachi having 2*playouts.
No large patterns in pachi and only 136 games were used (but the strong
decrease is significant I think)
The large pattern run is coming soon:)
Detlef
Am Donnerstag, den 19.12.2013, 19:52 +0100 schrieb Detlef Schmicker:
Thanks
OK, now I have 176 games fuego against pachi with same number of
playouts,
I will not spam more data for now, I think the point is, pachi is really
scaling good compared to fuego and oakfoam. We have a lot of work:)
Detlef
Am Freitag, den 20.12.2013, 14:18 +0100 schrieb Detlef Schmicker:
19x19
Thanks a lot for sharing so much information. I am checking all your
suggestions :)
I wonder, if the biggest difference between fuego, oakfoam compared to
pachi is not the use of progressive widening?!
This might be narrowing the search very good for low number of playouts,
but becoming useless
:)
Detlef
Am Samstag, den 23.11.2013, 11:32 +0100 schrieb Detlef Schmicker:
Just to let you know:
I did a comparison of the playings strength vs. playouts.
This time I used 4 times the oakfoam playouts for pachi
(eg. 1000 for oakfoam 4000 for pachi)
The graph shows how bad we become
um 10:53 Uhr
Von: Detlef Schmicker d...@physik.de
An: computer-go@dvandva.org
Betreff: Re: [Computer-go] Playouts vs playing strength
Hi,
I want to get more people interested into this scaling, therefore I did
also some scaling tests fuego against pachi :)
It is not as bad
+0100 schrieb Detlef Schmicker:
Just to let you know:
I did a comparison of the playings strength vs. playouts.
This time I used 4 times the oakfoam playouts for pachi
(eg. 1000 for oakfoam 4000 for pachi)
The graph shows how bad we become (in comparison) with more playouts
Thanks,
threads were set to 8 because of memory problems. My machines have 16GB
and 15GB.
I hoped the playing strenght would not differ too much, as I thought I
fixed the number of playouts. So it might be slower of cause...
At the moment I do not have disagrees about outcomes, but I will keep
Here are the results of fuego svn version
13x13 board, against pachi with pachi having 4*playouts
Totally 672 games...
I will give the 19x19 board a chance now:)
Detlef
Am Donnerstag, den 19.12.2013, 19:52 +0100 schrieb Detlef Schmicker:
Thanks,
threads were set to 8 because of memory
is, that the joseki becomes worse
with more playouts e.g.
http://www.physik.de/playouts2.pdf
The plot is 1050 games fitted with a 5th order polynome. The borders of
the plot are not statistical significant!
Thanks for every hint :)
Detlef
Am Montag, den 18.11.2013, 22:45 +0100 schrieb Detlef Schmicker:
Am
After turning off pondering in pachi the plot looks much more sensible:
http://physik.de/playouts.pdf
I will now do some comparison with proportional increasing playouts in
pachi and oakfoam.
Detlef
Am Montag, den 18.11.2013, 21:11 +0100 schrieb Petr Baudis:
On Sun, Nov 17, 2013 at
Thanks Nick,
as you ask both programmers to handle clean up correctly (round 2): I
would say NiceGo did. It is by design, that it passes for the end of
game if it counts a win with the clean-up rules.
If you think, this is wrong handling, please explain. Of cause we want
to do good handling of
Am Montag, den 18.11.2013, 21:11 +0100 schrieb Petr Baudis:
On Sun, Nov 17, 2013 at 03:11:22PM +0100, Erik van der Werf wrote:
make sure Pachi isn't doing any kind of pondering in the
background.
Indeed, Pachi will ponder by default. Turn pondering off by passing
pondering=0
, 2013 at 8:21 AM, Detlef Schmicker d...@physik.de wrote:
What is the experts guess?!
About what?
Maybe compare to Don's old study at
http://cgos.boardspace.net/study/index.html
Best,
Erik
___
Computer-go mailing list
Computer-go@dvandva.org
The graph seems not to displayed nice in all e-mail programs,
here is a link
http://physik.de/playouts.png
Am Sonntag, den 17.11.2013, 13:52 +0100 schrieb Detlef Schmicker:
Sorry,
as it is an logarithmic plot it looks like a limit of +150ELO. Do other
experience simelar results
I reasently did some tests to get an idea about the behaviour of oakfoam
with increased number of playouts.
I tested against gnugo, fuego and pachi 10.0
I show the result against pachi 10.0 with
pachi -d 0 -t =4000 -r chinese threads=1,max_tree_size=2048
200
Thanks for setting up the server. I wonder if it should work already?
I downloaded the client from your server, just in case it has changed,
but had the same result with the old clients
If I start my client with the domain changed to cgos.comoutergo.org it
seems to connect correctly but
is more important than playout quality
in small playouts like 700.
Regards,
Hiroshi Yamashita
- Original Message -
From: Detlef Schmicker d...@physik.de
To: computer-go@dvandva.org
Sent: Friday, August 30, 2013 6:41 PM
Subject: [Computer-go] Measuring program strength
Hi
Thanks Nick,
I love the slow bot tournaments.
Two reasons:
1) For me computer go is a hobby and to hire 6 cluster instances on EC2
is about 150$ for a tournament. 3 tournaments one i7-4770k:)
2) Not all programs can handle clusters. It is an additional problem for
authors, which are trying to
Hi,
I will try to fish for some secrets:)
Up to now I always was able to measure oakfoam improvenment by playing
against gnugo.
(700 playouts against gnugo level 10 and 300 playouts against gnugo
level 0)
But now we seem to be at a strenght, that makes this not very sensitive
anymore. I can
Thanks for the report. It was one of the observers who tested oakfoam
against gnugo 3.9, not me. Our actual download version is missing the
large pattern database, so it is not comparable I think.
We read the top left in the game not dead enough (90% dead). as it is a
big area this lead to
You are right, I did not see that I missed the w move, sorry for the
noise:(
Detlef
Am Dienstag, den 25.06.2013, 16:21 +0200 schrieb Erik van der Werf:
Are you looking at the initial state or the state after W j8 (after
which B J7 is self-atari, and W lives)?
Perhaps just show the
Hi,
oakfoam does not have such a feature yet. We have simelar features for
debugging, e.g. we could ask with which probability does a playout make
a point xy be owned black e.g. (and give an example playout)
But a possible approach would be straight forward I think. Change the
definition of
I wonder if anybody already compiled a mc go program for the haswell cpu
with auto-vectorization and avx2 enabled?
If I understood correctly it is the first intel cpu which can vectorize
integer operations, and go programs have a lot of them.
Detlef
As far as I know in free games the bot is not allowed to disagree.
You must test with rated games I am afraid
Detlef
Am Dienstag, den 11.06.2013, 13:21 -0400 schrieb Ed Poor:
Hi,
My KGS username is HelloCoder, and I need some help with GTP.
Specifically, is there any way to respond (in
I wonder if somebody tested the human playing strength versus bot
respond time on kgs (with the same bot parameters otherwize).
The reason I ask is: I want to test the scaling with playouts_per_move.
Aya is so kind to offer its playouts per move and I wondered if the
relatively bad scaling has to
Sorry it was my fault. NiceGo had rule all stones alive enabled before
round 9 (this option is for CGOS games). It was never a problem in
tournaments, as all games ended by resignation in the past.
Therefore they disagread about the dead stones, as NiceGo counted all
stones alive.
Me and NiceGo
Hi,
I think some mc bots play small margin games to the end now. Humans like
that. Before one of the bots resigned
Sometimes there is a weight of the margin in the evaluation: this leads
to winning with higher margin than 0.5. This is probably again to be
nice to humans and not playing
too
40 matches
Mail list logo
