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
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 respect
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
- 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 David
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 range of
with board size matters too.
It was not another criticism towards you opinion either.
- Message d'origine
De : Don Dailey [EMAIL PROTECTED]
À : computer-go computer-go@computer-go.org
Envoyé le : Vendredi, 26 Janvier 2007, 19h05mn 40s
Objet : Re: Re : [computer-go] an idea... computer go program's
PROTECTED]
À : computer-go computer-go@computer-go.org
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 +, ivan dubois wrote:
However, if you take for example a computer programm
- 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.
I am an
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 ask the
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 pairs,
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
[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
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
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
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
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 point
: 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 up a point here
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
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
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
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
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
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
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
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 there is
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
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 rating
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'
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
- 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 read m moves deep with a branching factor of b
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
Nick Apperson wrote
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 for
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
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
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
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
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 rare
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 scalable
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 increasing
39 matches
Mail list logo
