Quoting Nick Wedd n...@maproom.co.uk:
In message 20090622202905.utvbb8wkgk8cw...@webmail.phmp.se, Magnus
Persson magnus.pers...@phmp.se writes
I looked at the report and would like to give my opinion on why the
programs played as they did in the commented game between Zen and
Aya.
In
Quoting Brian Sheppard sheppar...@aol.com:
What komi did you use? It is nice to have the sgf in addition to the
position.
It is 7.5, and I do not have the SGF. I will try to create SGF for future
posts, to make reproduction easier for all.
Could it be that Pebbles have trouble seeing that
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
Hi,
CGOS 19x19 has stopped for a while.
Is server down?
If there is no enough anchor resource, I can run anchor (gnugo).
Regards,
Hiroshi Yamashita
___
computer-go mailing list
computer-go@computer-go.org
Christian (and anyone else interested) in the new CGOS protocol:
There are 2 minor change to the protocol. I'm hoping to do a test drive
today as the new server is functional, though not 100% complete.
Here are the two changes:
First of all, when the server asks for the protocol, you can
I restarted the 19x19 server.
Speaking of anchors ...
For the new server I'm thinking about making some specified version of fuego
the anchor on all venues. It seems to qualify as it has the following
characteristics:
1. open source.
2. high strength to cpu resource utilization ratio
I
I restarted the 19x19 server.
Thank you. I started my bot.
I'm thinking about making some specified version of fuego
I think using Fuego for anchor is good idea.
One problem is maybe latest Fuego will be overrated from
weak Fuego anchor.
Regards,
Hiroshi Yamashita
On Tue, Jun 23, 2009 at 10:10 AM, Hiroshi Yamashita y...@bd.mbn.or.jpwrote:
I restarted the 19x19 server.
Thank you. I started my bot.
I'm thinking about making some specified version of fuego
I think using Fuego for anchor is good idea.
One problem is maybe latest Fuego will be
Fuego gets an advantage because when it plays the anchor, it is playing a version of itself. That's bad for the same reason that it's bad to test against a
version of your own program -- inflated results. But I don't think it's a big deal. What about using both Fuego and Mogo as anchors?
Can you explain this? I don't understand what you are saying.
Once I ran both 1 core and 2 cores Aya on 19x19 CGOS, 2 cores Aya
got high rating. But without 1 core Aya, 2 cores Aya could not get
such a high rating.
Remi also reported same phenomenon.
[computer-go] CGOS Deflation or Self-Play
On Tue, Jun 23, 2009 at 10:22 AM, Michael Williams
michaelwilliam...@gmail.com wrote:
Fuego gets an advantage because when it plays the anchor, it is playing a
version of itself. That's bad for the same reason that it's bad to test
against a version of your own program -- inflated results.
Hi Don,
thank you, that is very useful. Definitely food for thought. I am
probably going to have time to take a look at this tomorrow. If you have
a developer copy of the server running on a private port, and can mail
me that off-list, I'd like to give it a try.
A few questions:
- What is
Is there statistical proof that this is a major issue? I have not reviewed
the reference to the forum post but I would like to say this:
If you expect something to happen, you will notice it when it does even if
what you think is happening really isn't.I'm not saying it didn't or
doesn't
Don,
One possibility would be to have two open-source anchors (fuego and gnugo?) and
ensure that a full-strength version would never be paired with it's own
limited-strength anchor version.
Ben.
From: Don Dailey dailey@gmail.com
To: computer-go
The server has no way of knowing which programs are related. The user is
free to choose any name and I don' t want to additional complexity to this.
- Don
2009/6/23 Ben Shoemaker plan...@rocketmail.com
Don,
One possibility would be to have two open-source anchors (fuego and gnugo?)
and
There has been some talk here of using a zero exploration coefficient.
Does this literally mean using the win ratio (with one dummy win per
node) to decide paths through the MC tree? It seems that the best move
could easily be eliminated by a couple of bad runs.
Does this only work when
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:
I believe we used a uniform random policy (only don't play in your
own pseudoeyes).
The numbers probably won't be the same, but we've certainly replicated
the qualitative improvement with version 6.05 of Orego, available here:
https://webdisk.lclark.edu/drake/orego/
Peter Drake
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
Yes, bad luck can be a problem.
Solutions:
1) RAVE/AMAF do bias good moves such that exploration take place anyway
2) Biased priors that initially forces many playouts for good
candidates, so that bad luck becomes less likely for moves that are
rated high using patterns or other means.
3)
There has been some talk here of using a zero exploration coefficient. Does
this literally mean using the win ratio (with one dummy win per node) to
decide paths through the MC tree? It seems that the best move could easily
be eliminated by a couple of bad runs.
Does this only work when using
2009/6/23 Olivier Teytaud teyt...@lri.fr:
By the way, the conditions for consistency in Astar, which is quite related
to Monte-Carlo Tree Search in my humble opinion, imply optimism in the sense
that the value must be overestimated. UCT/MCTS is really similar to Astar
without so-called close
I'm trying now to get a rough idea about the strength of fuego and it's
suitablity as the anchor player.
Right now the numbers are very rough as I need more samples. I'm currently
looking at:
1. 9x9 fuego at 1000 simulations
2. 19x19 fuego at 3000 simulations.
I'm testing against the
I'm running Fatman1, GNU Go and GNU Go MC version for 9x9 and two
instances of GNU Go for 13x13, five programs in total, on a dual-core
Athlon at home.
I strongly believe current anchors are resource friendly enough for
older pentium 3, 4 or even Celeron processors and not necessary being
If it were me, I'd run all anchor candidates against the current CGOS to
determine the anchor value to use for that anchor candidate.
Hideki Kato wrote:
I'm running Fatman1, GNU Go and GNU Go MC version for 9x9 and two
instances of GNU Go for 13x13, five programs in total, on a dual-core
I'd also prefer to use gnugo as an anchor. Since fuego is under
development, new versions will be playing with an odler version of itself.
Fuego will win more often against its old version. I don't care about it
distorting Fuego's rating, but it will distort the rating system. If new
fuego is
I agree with keeping the GnuGo anchor.
My understanding is that Don wanted to bundle one or more fast
programs with the server, so that some opponents would always be
available. But I think that the rating of bundled programs should not
be fixed.
Right now we're relying on volunteers to
If I were to change anchors I would of course carefully calibrate them.
But I don't see that fuego is stronger than Gnugo at the low CPU levels I
was hoping to run at. So there is no compelling reason right now to change
anchors.
- Don
On Tue, Jun 23, 2009 at 8:18 PM, Michael Williams
28 matches
Mail list logo
