You have inspired me to put Many Faces back on cgos, both 9x9 and 19x19,
using just one core on each, so it doesn't take much of my computing
resources. Testing against gnugo says going from 1 core to 4 cores is about
150 ELO for Many Faces. I should be able to keep Many Faces on CGOS
Here's a suggestion to extend RAVE to better handle it:
There are 20 points within keima distance of any point not close to the
edge.(5*5 without the corners)
When RAVE values are backed up, they are put into the category defined by
the previous opponents move.
(21 categories, 20 + other. All
The October 2009 KGS computer Go tournament will be this Sunday,
October 4th, in the Asian evening, European morning and afternoon,
and American night, starting at 08:00 UTC/GMT (09:00 BST) and
ending at 16:00 UTC/GMT (17:00 BST).
I have now accepted unofficial entries from
Fuego using the
Every now and then somebody submits an interesting 9*9 problem, usually
rendered in X and O.
Wouldn't it be great to have a public suite, lets say a directory with
black to play and win sgf problems.
For quick testing there should be only one correct first move.
There could also be
On Tue, Sep 29, 2009 at 12:12:07PM +0200, Stefan Kaitschick wrote:
Every now and then somebody submits an interesting 9*9 problem,
usually rendered in X and O.
Wouldn't it be great to have a public suite, lets say a directory
with black to play and win sgf problems.
For quick testing there
Hi!
On Mon, Sep 28, 2009 at 04:09:31PM -0600, Brian Sheppard wrote:
By now, I should probably find better reference opponent than
gnugo... I wonder if to pick fuego or mogo... ;-) Strength is probably
not _as_ important as the variety of techniques used in order to avoid
selective blindness
Hi ,
I remeber a version where the call was just
./cgosview-linux-x86_32 cgos.boardspace.net 6819
Hi!
How do I use cgosview-linux-x86_32? By default it connects to the
19x19 server and that works (displays empty game list window), but
I can't find out how to tell it to connect to
Hi!
On Tue, Sep 29, 2009 at 01:45:40PM +0200, Lars Schäfers wrote:
I remeber a version where the call was just
./cgosview-linux-x86_32 cgos.boardspace.net 6819
Ahh, thanks, that works. I think the website should be fixed then. :-)
Petr Pasky Baudis
*sigh*
I made a wiki for CGOS as part of the sourceforge project. I should
just take it down since it never became the official home page. I
don't even think it has a link to it from the official home page! Even
things like download links are duplicated...
Sent from my iPhone
On Sep 29,
I start with one move, and slowly add moves to the pool of moves to be
considered, peaking at considering 30 moves.
My current schedule looks like:
visits 0 2 5 9 15 24 38 59
90 100 ... 2142
moves 1 2 3 4 5
You have inspired me to put Many Faces back on cgos, both 9x9 and 19x19,
using just one core on each, so it doesn't take much of my computing
resources.
It will be wonderful to have an omnipresent omniscient opponent again. :-)
I'd suggest you put Pebbles on 19x19 also.
Pebbles and Many Faces
I'm not sure whether they meant different things when they were first coined,
but maybe that doesn't matter, and there are two different approaches that
should be distinguished somehow.
When a node has been visited the required number of times:
1) Use patterns, heuristics, ownership maps
hi;
I don't know to which extent my terminology is commonly used, but it seems
to be close to the distinction by Dave (but not exactly equal).
For me I use progressive widening when we add moves, progressively,
to the pool of moves which are to be considered;
whereas I use progressive
dhillism...@netscape.net wrote:
I'm not sure whether they meant different things when they were first coined,
but maybe that doesn't matter, and there are two different approaches that
should be distinguished somehow.
When a node has been visited the required number of times:
1) Use
I guess I'm not really appreciating the difference between node value
prior and progressive bias - adding a fixed small number of wins or
diminishing heuristic value seems very similar to me in practice. Is the
difference noticeable?
On Tue, Sep 29, 2009 at 08:25:56AM -0700, David Fotland wrote:
I guess I'm not really appreciating the difference between node value
prior and progressive bias - adding a fixed small number of wins or
diminishing heuristic value seems very similar to me in practice. Is the
difference noticeable?
It just means that the weight of the prior does not
I think someone pointed out a long time ago on this mailing list that
initializing the prior in terms of Rave simulations was far less efficient
than initializing the prior in terms of real simulations.
You might be recalling an exchange that I had with Sylvain. I asked how
initial bias was
Are you sure you are not over-tuning to some opponent, or to self-play? I
have a very simple formula, win rate plus rave (with the simpler beta
formula), plus the simple upper bound term. I bias the rave simulations
only. It seems to work pretty well. Your description sounds pretty
complex.
I haven't tested this, but my feeling is that it's better to test against
gnugo because it doesn't use uct/mc, so it has a very different style. But
mainly, I'm all set up with automated gnugo testing and it would take some
number of hours to convert to fuego. There is always something to code
This sounds like progressive widening, but it could still be progressive
unpruning, depending on implementation choices.
I do both. I have a small pool of moves that are active and I also bias the
initial rave values.
My current schedule looks like:
To be sure that I understand, MF
20 matches
Mail list logo
