Don,
you might have your work cut out if you try to control inflation
directly, that can turn into a black art very quickly. Multiple anchors
would be preferable. An offline, X * 1000 game playoff between gnugo and
another candidate anchor would be enough to fix their rating difference.
If th
>From what I have discovered so far, there is no compelling reason to change
anchors. What I really was hoping we could do is UPGRADE the anchor, since
many programs are now far stronger than 1800.
Fuego is pretty strong, but not when it plays at the same CPU intensity as
gnugo. I went up to 5
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 <
michae
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 p
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 on
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
Athl
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
chan
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 cu
2009/6/23 Olivier Teytaud :
> 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 set".
Can
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
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) One
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 state
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
http://ww
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:
An
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 u
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
> Don,
>
> One possibility would be to have two open-source anchors (fuego and gnugo?)
> and ensure that a full-s
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
To: computer-go
Sent: Tuesday, June 23, 2009
2009/6/23 Christian Nentwich
> 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
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 ha
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
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 result
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
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? Don't
On Tue, Jun 23, 2009 at 10:10 AM, Hiroshi Yamashita wrote:
> 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 fr
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
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 ha
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 cont
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
http://www.computer-go.org/mailman/listinfo/c
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 list
Quoting Brian Sheppard :
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 the semeai is won
a
30 matches
Mail list logo
