I'd really like to see how this does against traditional programs. If Don
sets up
a 19x19 server I'll put Many Faces of Go on it.
David
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Chaslot G (MICC)
> Sent: Tuesday, December 12, 2006 1:17 AM
There are 30 or 40 thousand pro games available - try Go Games on Disk.
There are 40K strong amateur games available on the Many Faces of Go CD-ROM
I think KGS amateur games are available for free.
David
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
Maybe not 10,000, but 1,000 yes. The current CPUs are 90 nm or 65 nm
process nodes, and labs know how to scale down to 10 nm or so. That's an
area density increase of 50 to 100.
Look at RAMP,
http://www.eecs.berkeley.edu/BEARS/presentations/06Patterson.ppt a research
project to figure out how
> I suggest you use anchorman. It will be weaker on 19x19, but so will the
> other programs.
It depends on the programs. Gnugo or Aya scale very well on 19x19. Then
anchorMan would be far too weak for Aya and gnugo, and certainly other
programs. But we can try some experiments, and perhaps chang
I suggest you use anchorman. It will be weaker on 19x19, but so will the
other programs.
It lets you get set up quickly.
David
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Don Dailey
> Sent: Tuesday, December 12, 2006 10:48 AM
> To: computer-g
Le Mercredi 13 Décembre 2006 05:56, Don Dailey a écrit :
> On Wed, 2006-12-13 at 04:48 +0100, [EMAIL PROTECTED] wrote:
> > > GnuGo is another possibility and has the advantage of being a well
> > > known quantity, but Gnugo fails to meet some of the criteria above
> > > such as being too determinis
1 kyu difference means 1 handicap stone for an even game. 3 kyu
difference is 3 handicap stones for an even game. It is not transitive or
linear. 1 handicap stone means no komi, so the 1 stone difference is half
as
big as the step between 2 stones and 3 stones. Larger handicap give larger
adva
On Wed, 2006-12-13 at 04:48 +0100, [EMAIL PROTECTED] wrote:
> > GnuGo is another possibility and has the advantage of being a well
> > known quantity, but Gnugo fails to meet some of the criteria above
> > such as being too deterministic and using heavy resources.
But GnuGo uses a lot of memory, o
Hi Sylvain,
I'm not worried about the ELO situation but you are right. When skill
is measured by ELO you are talking about the probability of winning a
game against any given opponent, we just have to be careful how we
interpret or compare to other board sizes.
If 2 opponents are 50 ELO rating p
> GnuGo is another possibility and has the advantage of being a well
> known quantity, but Gnugo fails to meet some of the criteria above
> such as being too deterministic and using heavy resources.
Hello,
GnuGo at level 0 met almost all requirement I think. Perhaps too
deterministic, but I even
I merely suggest that introducing two servers at the same time would
effect in too small number of players on any of them. Delaying 19x19
by 3 months is natural and give people time to develop new scalable
techniques at 13x13.
In other words I believe that lone 19x19 is to big jump and many
peop
If I set up a 19x19 server, we will need an Anchor player. Here is
what I need from an Anchor player:
1. Non-deterministic - should not play same game every time.
2. Consistent - plays at the same strength at a level that is not
based on the power of the hardware. For instance Anch
If I set up a 19x19 server, we will need an Anchor player. Here is
what I need from an Anchor player:
1. Non-deterministic - should not play same game every time.
2. Consistent - plays at the same strength at a level that is not
based on
the power of the hardware. For instance Anch
What happens in March?
Or are you suggesting that we do 13x13 until March?
- Don
On Tue, 2006-12-12 at 17:54 +0100, Łukasz Lew wrote:
> I vote for 13x13 with 15 minutes.
> 19x19 , 30 minutes , in march.
>
> Lukasz Lew
>
> On 12/12/06, Don Dailey <[EMAIL PROTECTED]> wrote:
> > We have a few pro
I vote for 13x13 with 15 minutes.
19x19 , 30 minutes , in march.
Lukasz Lew
On 12/12/06, Don Dailey <[EMAIL PROTECTED]> wrote:
We have a few proposals. My preference is 13x13 at 20 minutes per
game, but I think the idea of having 19x19 is more popular.
If we do 19x19 I don't think the monte
I vote for adding both 13x13 and 19x19. As long as there is capacity on the
server, I don't see any harm in running all three common sizes at the same
time. Let the usage dictate how to proceed from there. This may provide
valuable feedback that can been incorporated into the new server Don i
I vote for 13x13.
On 12/12/06, Edward de Grijs <[EMAIL PROTECTED]> wrote:
Just realize that with 30 minutes for each side, each round will be 1 hour,
so for a reasonable rating (which is debatable) of 170 games this will
mean that one computer has to compete one complete week continuously.
I na
Just realize that with 30 minutes for each side, each round will be 1 hour,
so for a reasonable rating (which is debatable) of 170 games this will
mean that one computer has to compete one complete week continuously.
I naturally will use the 19x19 server, but it will be not often that I can
play
We have a few proposals. My preference is 13x13 at 20 minutes per
game, but I think the idea of having 19x19 is more popular.
If we do 19x19 I don't think the monte carlo programs would have much of
a chance with current hardware if we use a fast time control.Of
course personally I'm trying
You anticipated my next question - the time control.
I was thinkin gof 30 minutes too. Any feedback?
- Don
On Mon, 2006-12-11 at 21:10 -0800, David Fotland wrote:
> I'd like to see 19x19. No one plays the game on any other board size than
> 19x19, so the other sizes are not very interesting.
20x is not really correct ( unless I've misunderstood something ). The
games are on average 4x longer for my rudimentary UCT-MC program on
19x19 boards ( about 450 moves, standard eye-rule only ). However,
simulations per/sec is only down 5x. So, in order to get the same
number of simulations per
I don't need to see a 19x19 server to tell me it's going to be too
slow. But the question is how slow. So I think David Doshay had the
right suggestion to try incrementally larger board-sizes. But there
are a few limitations. One is that the increments still go in two's,
as the board needs
I noticed a few papers now mention Bayesian learning
techniques for mining for patterns and I am curious
where does one find libraries for this sort of thing
are there some commercially or free game libraries to
which the procedures described can be applied.
Regards,
Carter.
_
Hi David,
I have scaled my Monte-Carlo program (Mango) to 19x19.
My idea is to bias the UCT distribution including big patterns. This
seems to work quite well, and to lead to a much more human-like kind of
play then pure Monte Carlo. The patterns were learnt automatically from
professional games
If the simulated games are about 5x longer, and the board is over 4x bigger,
then we would need over 20x the time to get the same number of simulations
per position evaluated by UCT. I suspect the larger board will need may
more simulations to get a reliable score.
How about 20 minutes per side?
25 matches
Mail list logo
