gt; Envoyé le : Vendredi, 26 Janvier 2007, 19h51mn 10s
> Objet : Re: Re : [computer-go] an idea... computer go program's rank vs time
>
>
> >Part of my procrastination is that I'm not sure how to make UCT
> >scale to a large number of CPU's.I am an expert in
On Fri, 2007-01-26 at 14:47 -0500, Chris Fant wrote:
> I personally would love to see more experimental results and less
> feelings and intuitions on this list.
I agree. I will post my data as I go. Just for reference, this
is the the Lazarus program that is currently rated at 1807 on CGOS
but
On Fri, 2007-01-26 at 14:43 -0500, Don Dailey wrote:
> I don't currently have the data, but I am willing to reproduce
> the experiment. Other MC guys can verify it. I'll set it up
> on a slow computer I have free and I'll start at 64 simulations
> on a 19x19 board.I'll play 200 games in pair
Isn't UCT equivalent to Alpha-beta with some cleaver pruning rules ?
- Message d'origine
De : Don Dailey <[EMAIL PROTECTED]>
À : computer-go
Envoyé le : Vendredi, 26 Janvier 2007, 19h51mn 10s
Objet : Re: Re : [computer-go] an idea... computer go program's rank
I personally would love to see more experimental results and less
feelings and intuitions on this list.
On 1/26/07, Don Dailey <[EMAIL PROTECTED]> wrote:
On Fri, 2007-01-26 at 11:32 -0800, terry mcintyre wrote:
>
> - Original Message From: Don Dailey <[EMAIL PROTECTED]>
> >
> > May I a
On Fri, 2007-01-26 at 11:32 -0800, terry mcintyre wrote:
>
> - Original Message From: Don Dailey <[EMAIL PROTECTED]>
> >
> > May I ask the range of "number of playouts" tested?
>
> I'm still curious about this question?
I think I started at 64 play-outs, and kept doubling the number
of
- Original Message From: Don Dailey <[EMAIL PROTECTED]>
>
> May I ask the range of "number of playouts" tested?
I'm still curious about this question?
> Part of my procrastination [ about using 72 processors ] is that
> I'm not sure how to make UCT scale to a large number of CPU's.
>
gt;
> - Message d'origine
> De : Don Dailey <[EMAIL PROTECTED]>
> À : computer-go
> Envoyé le : Vendredi, 26 Janvier 2007, 19h05mn 40s
> Objet : Re: Re : [computer-go] an idea... computer go program's rank vs time
>
>
> On Fri, 2007-01-26 at 13:38 +
board size matters too.
It was not another criticism towards you opinion either.
- Message d'origine
De : Don Dailey <[EMAIL PROTECTED]>
À : computer-go
Envoyé le : Vendredi, 26 Janvier 2007, 19h05mn 40s
Objet : Re: Re : [computer-go] an idea... computer go program's rank
On Fri, 2007-01-26 at 10:22 -0800, terry mcintyre wrote:
>
> - Original Message From: Don Dailey <[EMAIL PROTECTED]>
>
> >This can be tested directly. In my own experiments 19x19
> > improves very rapidly in UCT with each doubling of the
> > number of play-outs.
>
> May I ask the
- Original Message From: Don Dailey <[EMAIL PROTECTED]>
>This can be tested directly. In my own experiments 19x19
> improves very rapidly in UCT with each doubling of the
> number of play-outs.
May I ask the range of "number of playouts" tested?
Have you considered taking up Da
On Fri, 2007-01-26 at 13:38 +, ivan dubois wrote:
> However, if you take for example a computer programm that does
> straight UCT (global UCT, with no sub-areas), then i believe it can
> not scale well when board size increases. Because the branching would
> factor increase proportinaly to the
I second Mark Boon's comment.
On 1/26/07, Mark Boon <[EMAIL PROTECTED]> wrote:
Am I the only one who got tired of this rather pointless discussion a
hundred messages ago? I also can't help feeling that the tone of the
discussion tends to get such that it can easily be mistaken for lack
of respec
mputer-go
Envoyé le : Vendredi, 26 Janvier 2007, 14h10mn 08s
Objet : Re: [computer-go] an idea... computer go program's rank vs time
On Fri, 2007-01-26 at 02:41 -0600, Nick Apperson wrote:
> I am not trying to say that you don't know what you are talking about,
> but how are y
On Fri, 2007-01-26 at 02:41 -0600, Nick Apperson wrote:
> I am not trying to say that you don't know what you are talking about,
> but how are you so sure that we must be on the linear part of the
> curve? Based on what you said, I estimate your ideal (non empirical)
> formula to be something like
here's my attempt to talk about how a 9x9 algorithm should be expected
to scale on a bigger board, and what limits we can expect to have on
perfect algorithms. i'm kind've trying to bridge the divide here. maybe
it's silly. hopefully the experts can correct me.
saying that doubling computer tim
Am I the only one who got tired of this rather pointless discussion a
hundred messages ago? I also can't help feeling that the tone of the
discussion tends to get such that it can easily be mistaken for lack
of respect for each other. Can we get back to more mundane issues,
like how MC scal
On 1/25/07, Don Dailey <[EMAIL PROTECTED]> wrote:
On Thu, 2007-01-25 at 20:16 -0600, Matt Gokey wrote:
> Don Dailey wrote:
> > You are still missing the point.
> I can say the same of you.
>
> I merely am raising a question about the assertion that doubling of
> _human_ thinking time results in
Hi Don,
On 1/25/07, Don Dailey <[EMAIL PROTECTED]> wrote:
That's the thought - due
> to
> the nature of go the increases might not be linear nor consistent
> between players of different strengths. I hesitate to venture what
> others believe, but it seems based on Ray's and Mark's and others'
On Thu, 2007-01-25 at 21:40 -0600, Matt Gokey wrote:
> terry mcintyre wrote:
> > let's step back a bit and define terms. How do we define "a linear
> > improvement in Go"?
> Don can correct me if I'm wrong,
>
> The hypothesis is: For any player rating each doubling of thinking time
> creates a r
On Thu, 2007-01-25 at 21:44 -0600, Matt Gokey wrote:
> Let me expand on this. Perhaps due to the nature of Go and
> the human style learning needed to judge some moves and positions to
> be
> advantageous many (like 20-60+) stones out with possible interplay
> between groups (a tree which cannot p
Matt Gokey wrote:
I was trying to compare a different relationship related to the
branching factor and other characteristics of Go to capacity of human
logical reasoning and thinking. The idea being to suggest a possible
explanation for why Go may be qualitatively different than Chess in this
On Thu, 2007-01-25 at 20:16 -0600, Matt Gokey wrote:
> Don Dailey wrote:
> > You are still missing the point.
> I can say the same of you.
>
> I merely am raising a question about the assertion that doubling of
> _human_ thinking time results in _linear_ improvements. I am not
> claiming that t
terry mcintyre wrote:
let's step back a bit and define terms. How do we define "a linear
improvement in Go"?
Don can correct me if I'm wrong,
The hypothesis is: For any player rating each doubling of thinking time
creates a rating increase by a fixed constant value.
Would that be a linear
let's step back a bit and define terms. How do we define "a linear improvement
in Go"?
Would that be a linear increase in ELO points, or what?
Terry McIntyre
Want to start your own business?
Learn how on
Don Dailey wrote:
You are still missing the point.
I can say the same of you.
I merely am raising a question about the assertion that doubling of
_human_ thinking time results in _linear_ improvements. I am not
claiming that there is no improvement - never have. I am not claiming
that every
Vlad Dumitrescu wrote:
Hi Matt,
On 1/25/07, Matt Gokey <[EMAIL PROTECTED]> wrote:
But just because a rule of thumb holds for Chess doesn't mean it does
for Go. Of course I could be wrong, but I was just trying to introduce
reasonable doubt, since Don always seems so sure of himself ;-)
If I
That was just a statement, "I have never advocated WASTING power" to
help
make it clear that I believe in squeezing the most out of each cpu
cycles,
not just making some algorithm as fast as it can be but also using the
best algorithms.
I did not take your post as some kind of contradictory stat
We are thinking about it, but others have code that is far ahead
of whatever our first effort is likely to produce, so I favor a
collaboration.
We are still investigating behavior that we do not expect from
SlugGo, and we are working on a number of fronts to move
from where we have been (using mu
Have you considered refocusing towards MC Go?
On 1/25/07, David Doshay <[EMAIL PROTECTED]> wrote:
On 25, Jan 2007, at 10:14 AM, terry mcintyre wrote:
> So what would it take to get corporate sponsorship of the sort which
> drove the chess computing field? Where is the Go equivalent of Deep
>
I don't rememeber citing you as saying that. My however was in reference to
myself.
On 1/25/07, Don Dailey <[EMAIL PROTECTED]> wrote:
On Thu, 2007-01-25 at 12:17 -0600, Nick Apperson wrote:
> I am writing my program to scale to n processors because I think that
> is the direction hardware is h
On 25, Jan 2007, at 10:14 AM, terry mcintyre wrote:
So what would it take to get corporate sponsorship of the sort which
drove the chess computing field? Where is the Go equivalent of Deep
Thought?
The Japanese Govt and industrial sponsorship of the Fifth Generation
Project, which did have pl
On Thu, 2007-01-25 at 12:17 -0600, Nick Apperson wrote:
> I am writing my program to scale to n processors because I think that
> is the direction hardware is headed. However, I think clever
> programming will do more than computational power with go.
I take the point of view that clever programm
On Thu, 2007-01-25 at 17:41 +, Stuart A. Yeates wrote:
> 0. with probably P, play a random move (using the same selection
> methodology as the random player)
>
>
>1. play 1 random game.
>
>2. If black wins, play one of the first N black moves in
> t
I am writing my program to scale to n processors because I think that is the
direction hardware is headed. However, I think clever programming will do
more than computational power with go.
On 1/25/07, terry mcintyre <[EMAIL PROTECTED]> wrote:
So what would it take to get corporate sponsorship
So what would it take to get corporate sponsorship of the sort which
drove the chess computing field? Where is the Go equivalent of Deep
Thought?
Near as I can tell, David Doshay's Sluggo is the only large-scale
parallel effort. Mogo uses at most 4 CPUs. What might be accomplished
with one of the
ofcourse you are correct, P = 1.0 is just the random player. Obviously the
ELO as a function of P is going to be continuous. So, being really close to
P=1.0 will make for a player that is only very slightly better than random.
I think it is also interesting to consider a player worse than rando
On 1/25/07, Don Dailey <[EMAIL PROTECTED]> wrote:
I also had a difficult time producing a player that was less than
200 ELO stronger than a random player. Even a single play-out,
which seems hardly enough to discriminate between moves, is
enormously stronger than a random player.It was pr
M
Subject: Re: [computer-go] an idea... computer go program's rank vs time
Go, being a matter of efficiency over one's opponent, may be even more
susceptible to improvement via many small improvements over many moves than is
chess. As long as you don't leave weak shapes behind, picking
On Thu, 2007-01-25 at 08:23 -0800, terry mcintyre wrote:
> Go, being a matter of efficiency over one's opponent, may be even more
> susceptible to improvement via many small improvements over many moves
> than is chess. As long as you don't leave weak shapes behind, picking
> up a point here, a poi
Go, being a matter of efficiency over one's opponent, may be even more
susceptible to improvement via many small improvements over many moves than is
chess. As long as you don't leave weak shapes behind, picking up a point here,
a point there at a slightly faster rate than your opponent will giv
On Thu, 2007-01-25 at 03:27 -0600, Matt Gokey wrote:
> Learning these skills while thinking about a particular game's next
> move
> is not generally practical and even if possible would presumably
> require
> enormous extra time. Yet without this ability you are left with a
> massively rapid exp
Hi Matt,
On 1/25/07, Matt Gokey <[EMAIL PROTECTED]> wrote:
But just because a rule of thumb holds for Chess doesn't mean it does
for Go. Of course I could be wrong, but I was just trying to introduce
reasonable doubt, since Don always seems so sure of himself ;-)
If I may venture trying to re
[EMAIL PROTECTED] wrote:
Yes. Don's scalability argument states that ELO gain is proportional
to time doubling.
For me scalable use of time implies that time translates into depth.
The extra depth is:
m - m0 = log(2)/log(b).
So if the ELO gain for time doubling in Chess equals 100 over a wi
Ray Tayek wrote:
... I can say that I don't feel overwhelmed when playing chess. ...
Now with Go as a beginner still, on the other hand, I almost always
felt and still feel quite overwhelmed ...
yes, i usually feel this way in tournament games. and again more time
will help (for some smal
On Tue, 2007-01-23 at 21:08 +0100, [EMAIL PROTECTED] wrote:
> Yes. Don's scalability argument states that ELO gain is proportional
> to time doubling.
> For me scalable use of time implies that time translates into depth.
> The extra depth is:
>
> m - m0 = log(2)/log(b).
>
> So if the ELO gain
cause of the larger branching factor.
On 1/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
- Oorspronkelijk bericht -
Van: Matt Gokey <[EMAIL PROTECTED]>
Datum: maandag, januari 22, 2007 9:59 pm
Onderwerp: Re: [computer-go] an idea... computer go program's rank vs
time
- Oorspronkelijk bericht -
Van: Matt Gokey <[EMAIL PROTECTED]>
Datum: maandag, januari 22, 2007 9:59 pm
Onderwerp: Re: [computer-go] an idea... computer go program's rank vs
time
> Nick Apperson wrote:
>
> > He is saying this (I think):
> >
> > to
At 09:27 AM 1/22/2007, you wrote:
...
Don believes there is probably no difference and
states a rule: doubling thinking time = linear improvement in play.
i agree with this over some small range of powers of two.
..., as breaking the game into regions and doing
local reading and global analy
Nick Apperson wrote:
He is saying this (I think):
to read m moves deep with a branching factor of b you need to look at p
positions, where p is given by the following formula:
p = b^m (actually slightly different, but this formula is close enough)
which is:
log(p) = m log(b)
m = log(p) /
Don Dailey wrote:
Thanks Don, overall you may have missed my point. I am not saying that
human thinking time does not help in go like in chess, but rather that
the relationship (the curve) between thinking time and strength may not
be the same between chess and go as I thought you had been as
He is saying this (I think):
to read m moves deep with a branching factor of b you need to look at p
positions, where p is given by the following formula:
p = b^m (actually slightly different, but this formula is close enough)
which is:
log(p) = m log(b)
m = log(p) / log(b)
We assume that a
[EMAIL PROTECTED] wrote:
What if we look at it mathematically by looking at the branching
factor?
Go’s branching factor is generally considered to be about an order
of
magnitude greater than chess – perhaps a bit less, right? That
means
that after each ply go becomes another additional orde
Hi Matt,
What you wrote is well thought out. I give some comments.
On Mon, 2007-01-22 at 11:27 -0600, Matt Gokey wrote:
> Been following this thread pretty closely and thought I would jump in
> with a thought and try to find some common ground. I think there is
> truth to be found in both s
- Oorspronkelijk bericht -
Van: Matt Gokey <[EMAIL PROTECTED]>
Datum: maandag, januari 22, 2007 6:27 pm
Onderwerp: Re: [computer-go] an idea... computer go program's rank vs
time
> Been following this thread pretty closely and thought I would jump
> in
> with a tho
Been following this thread pretty closely and thought I would jump in
with a thought and try to find some common ground. I think there is
truth to be found in both sides of this argument.
Of course people improve with time and so do computers with certain
algorithms. The question is about th
> Note that professionals do not play perfect endgame, ...
Enough, apparently, that it separates a world champion from a
run-of-the-mill 9-dan.
> Also, post-mortem analysis of pro games published in go magazines
> routinely finds some game-result changing improvements in the endgame.
Yes, though
2007/1/22, Darren Cook <[EMAIL PROTECTED]>:
A couple of related comments. First, in the 2-day games the pros spend
almost all their thinking time in the opening, i.e. considering
different joseki and how they work together. By the time they get into
the endgame they are playing almost all moves
It is true that MC-programs has a bias towards overconcentration. But...
1) A improvements to the simulations of MC-program as implemented by MoGo and
Valkyria does diminish the problem. In fact most of the strength of these
programs from doing that. I think it is next to possible to explicitly p
> take a look at some of the corner josekis, some of them has *many*
> variations (http://en.wikipedia.org/wiki/Taisha_joseki) and go for
> *many* moves (50+?). most humans can't choose the best variation that
> takes advantage of the stones in the adjacent corners ...
A couple of related comments
At 09:38 PM 1/21/2007, you wrote:
On Sun, 2007-01-21 at 20:29 -0800, terry mcintyre wrote:
...
> Most programs reach scalability limits at some point. ...
Where most people go wrong is to assume that for a computer to beat
a human it must be able to understand every single thing a human does
bu
On Sun, 2007-01-21 at 20:29 -0800, terry mcintyre wrote:
> From: Don Dailey <[EMAIL PROTECTED]>
>
> On Mon, 2007-01-22 at 03:43 +0100, alain Baeckeroot wrote:
> > The few games i played against mogobot on 19x19 shows that it does
> not
> > "know" overconcentration. And i can safely bet that increa
From: Don Dailey <[EMAIL PROTECTED]>
On Mon, 2007-01-22 at 03:43 +0100, alain Baeckeroot wrote:
> The few games i played against mogobot on 19x19 shows that it does not
> "know" overconcentration. And i can safely bet that increasing
> thinking time will not solve this,
>By definition, a scalabl
On Mon, 2007-01-22 at 03:43 +0100, alain Baeckeroot wrote:
> The few games i played against mogobot on 19x19 shows that it does not
> "know" overconcentration. And i can safely bet that increasing
> thinking
> time will not solve this,
By definition, a scalable program can solve all problems so
y
Le dimanche 21 janvier 2007 19:02, Don Dailey a écrit :
> On Sun, 2007-01-21 at 13:34 -0200, Mark Boon wrote:
> > To move
> > up 200 ELO points in Go is usually not achieved by looking at more
> > positions but by acquiring new concepts. To acquire a new concept in
> > just a few hours is a r
65 matches
Mail list logo
