[EMAIL PROTECTED] wrote:
> Doesn't the total number of playout simply relates to the search ply depth?
>
There is a relation, but it's not "simple." The more playouts you
do, the more lines you will explore to deeper depths.
My suspicious is that with lighter playouts, you will tend to ex
[EMAIL PROTECTED] wrote:
Doesn't the total number of playout simply relates to the search ply depth?
I have no idea what you mean or what the relevance is in the discussion.
--
GCP
___
computer-go mailing list
computer-go@computer-go.org
http://www.
Doesn't the total number of playout simply relates to the search ply depth?
DL
-Original Message-
From: Gian-Carlo Pascutto <[EMAIL PROTECTED]>
To: computer-go
Sent: Fri, 11 Apr 2008 10:01 am
Subject: [computer-go] Scalability study request
Hi all,?
?
the result of the scalability stu
Don Dailey wrote:
Gian-Carlo,
We could probably add this new version to the mix and extend the
study.But what kind of data has your own testing produced? Do you
have an indication that it is roughly as strong at the same basic time
setting (because of it's being 3X faster or so?)
It is d
Gian-Carlo,
We could probably add this new version to the mix and extend the
study.But what kind of data has your own testing produced? Do you
have an indication that it is roughly as strong at the same basic time
setting (because of it's being 3X faster or so?)
Even if it isn't, it would
If we can get some consensus on what to test, we can do more.Or we
can add 1 program version to the current study.
Any ideas?(Or we could do a 19x19 study.)
- Don
terry mcintyre wrote:
> If we start up another scalability test, I'd be
> delighted to offer up a few computer cores.
>
Olivier Teytaud wrote:
light-playout variant of leela, but perhaps the
nakade-patch version of mogo and maybe even some third
no problem for the nakade-patch version of mogo, but results
are only known in 9x9, no idea for 13x13. Maybe it is better,
maybe it is worse :-)
At 9x9 you see a dimin
Good to find out, no?
we have validated that:
- it is good in 9x9;
- it is bad in 19x19 (unless perhaps for very large number of
simulations).
we did not have a look at 13x13.
___
computer-go mailing list
computer-go@computer-go.org
http://www.compu
--- Olivier Teytaud <[EMAIL PROTECTED]> wrote:
> > light-playout variant of leela, but perhaps the
> > nakade-patch version of mogo and maybe even some
> third
>
> no problem for the nakade-patch version of mogo, but
> results
> are only known in 9x9, no idea for 13x13. Maybe it
> is better,
> m
simulations is perhaps not always a good idea.)
Is the "patch" in some way parameterized by the number of simulations?
No. Perhaps it should :-)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/comp
Olivier Teytaud wrote:
I am now wondering if scalability could be unaffected by playouts
(just adding a constant offset) and only depend on the UCT/search
implementation. From the publications of the MoGo team it seems likely
that the programs are very similar there.
Leela and mogo are probab
light-playout variant of leela, but perhaps the
nakade-patch version of mogo and maybe even some third
no problem for the nakade-patch version of mogo, but results
are only known in 9x9, no idea for 13x13. Maybe it is better,
maybe it is worse :-)
___
If we start up another scalability test, I'd be
delighted to offer up a few computer cores.
It would be real nice to not only have the
light-playout variant of leela, but perhaps the
nakade-patch version of mogo and maybe even some third
program. ( if wishes were horses ... )
Terry McIntyre <[E
I am now wondering if scalability could be unaffected by playouts (just
adding a constant offset) and only depend on the UCT/search implementation.
From the publications of the MoGo team it seems likely that the programs are
very similar there.
Leela and mogo are probably quite similar.
On the
Hi Chuck,
Thank you for your interesting suggestions.I have previously
considered a system where the distribution is based on how many
contestants. For instance if there are hundreds of players you would
want to generate best of 5 or 6 or more, but if there were only 3 or 4
you might want be
i agree with everything except for the seeding. it takes very few games
(especially with the distribution you suggest) to get somewhat near the
right spot. with 500-ish games being played per player, the initial time
to get into the right place isn't unreasonable.
keep in mind that if you totall
Le vendredi 1 février 2008, terry mcintyre a écrit :
> Regarding the scalability study,
...
> I'm very curious about that flat spot for
> Mogo-16, 17, and 18. ( http://cgos.boardspace.net/study/index.html )
>
I think its just lack of data
Mogo_16 = 2958+47 / -45
Mo
>>> ... it would explain the scaling curve flattening out.
>>>
>> Though the curve can also be flattened/made-curvier by changing the base
>> of the x-axis. Currently it is log-2. Proportional to actual playouts
>> would make it appear flatter.
>>
> No, that would make it appear more curved
May I suggest a fundamental limit to the utility of this scalability study?
We are comparing three programs to each other, IIRC - Fatman, Mogo, and Gnugo.
All three are known to have certain odd little quirks. The two MC programs, in
particular, are
known to be deficient when addressing certain
Just cool it. We intend to add 3 more mogo levels soon.
- Don
Christoph Birk wrote:
> On Wed, 23 Jan 2008, Don Dailey wrote:
>> This bias was clear in 7x7 - I don't expect to see it here but I will
>> check when there are enough games at the upper levels.
>
> I beg you ... add Mogo_14 to
Darren Cook wrote:
>> ... it would explain the scaling curve flattening out.
>>
>
> Though the curve can also be flattened/made-curvier by changing the base
> of the x-axis. Currently it is log-2. Proportional to actual playouts
> would make it appear flatter.
>
No, that would make it app
On Wed, 23 Jan 2008, Don Dailey wrote:
This bias was clear in 7x7 - I don't expect to see it here but I will
check when there are enough games at the upper levels.
I beg you ... add Mogo_14 to the study, please.
Christoph
___
computer-go mailing lis
This bias was clear in 7x7 - I don't expect to see it here but I will
check when there are enough games at the upper levels.
- Don
David Fotland wrote:
> Since the komi contains a half point, there should be almost no ties, and
> between two perfect players, one color will always win by half a p
In message
<[EMAIL PROTECTED]>, Russ
Williams <[EMAIL PROTECTED]> writes
A couple of technical nitpick questions:
On Jan 23, 2008 5:57 AM, David Fotland <[EMAIL PROTECTED]> wrote:
Since the komi contains a half point, there should be almost no ties,
How should there be "almost no" ties, inst
A couple of technical nitpick questions:
On Jan 23, 2008 5:57 AM, David Fotland <[EMAIL PROTECTED]> wrote:
> Since the komi contains a half point, there should be almost no ties,
How should there be "almost no" ties, instead of "no" ties, with the
half point in the komi? (Or are you thinking of
> ... it would explain the scaling curve flattening out.
Though the curve can also be flattened/made-curvier by changing the base
of the x-axis. Currently it is log-2. Proportional to actual playouts
would make it appear flatter.
Darren
___
computer-
One way to estimate the scalability against human players is to start with a
program with a well established raking in with human games. Then
reduce the simulation time and see how the ranking drops.
AOL now offers fr
On Thu, 2007-06-28 at 18:38 +0100, Jacques Basaldúa wrote:
> I am afraid today a postal chess game is a computer analyst
> against another computer analyst. An interesting challenge,
> no doubt, but that has little to do with chess.
I don't agree with this. I have heard it can improve your real
Don Dailey wrote:
> I don't know if this is very popular any longer due to the
> Internet but I'm going back a few years.
I am afraid today a postal chess game is a computer analyst
against another computer analyst. An interesting challenge,
no doubt, but that has little to do with chess.
Anoth
some dame are actually outside liberties, so it's important
to be careful with them as well.
s.
- Original Message
From: Chris Fant <[EMAIL PROTECTED]>
To: computer-go
Sent: Wednesday, June 27, 2007 6:41:23 PM
Subject: Re: [computer-go] scalability study - final results
&
That still doesn't deal with dame though. Dame points always come out
as not owned much by either side.The algorithm might be to do a
simple test for dame and if it looks like a dame point and the ownership
map is close to neutral, then it's probably a dame point. Maybe dame
isn't that har
On Wed, 2007-06-27 at 17:52 -0400, Chris Fant wrote:
> I think the correct solution would probably have something to do with
> generating an expected teritory map during your UCT simulations and
> then prunning moves from the root that are in strongly owned enemy
> territory (and you would also som
It's an interesting problem - how to make a Chinese based UCT program
play by Japanese rules.I don't think it would be very easy to do
that well.
I would think you would need a separate system (with perhaps some
support from UCT) which could identify moves that should be avoided.
Without hav
On Wed, 2007-06-27 at 13:58 -0700, terry mcintyre wrote:
> If I recall correctly, Chinese rules encourage you to fill dame, since
> stones on the board are counted; Japanese rules exact no penalty
> either way since dame are not territory.
>
> Under Chinese rules, it would be foolish to pass so lo
Subject: Re: [computer-go] scalability study - final results
On Wed, Jun 27, 2007 at 04:03:09PM -0400, Don Dailey wrote:
> My program wouldn't do well as it would not understand dame and other
> Japanese complexities.
It should not do too badly - if you play by the chinese rules, you wi
On Wed, Jun 27, 2007 at 04:03:09PM -0400, Don Dailey wrote:
> My program wouldn't do well as it would not understand dame and other
> Japanese complexities.
It should not do too badly - if you play by the chinese rules, you will
do quite well by the japanese as well. Perhaps some of the opponents
I noticed there was a robot interface of some kind too.
My program wouldn't do well as it would not understand dame and other
Japanese complexities.
For a long time I have considered trying to have a Japanese mode but I'm
not yet motivated enough to do this. I might consider it if I ever get
it
l; but they mean to govern. They promise to be kind
masters; but they mean to be masters. -- Daniel Webster
- Original Message
From: Christoph Birk <[EMAIL PROTECTED]>
To: computer-go
Sent: Wednesday, June 27, 2007 12:33:59 PM
Subject: Re: [computer-go] scalability study - final res
On Wed, 27 Jun 2007, steve uurtamo wrote:
uucgs.
could probably be written as a small wrapper around
uucp over ethernet. :)
At that pace you may just do it by hand ... sending the
move by email.
Christoph
___
computer-go mailing list
computer-go@c
uucgs.
could probably be written as a small wrapper around
uucp over ethernet. :)
s.
- Original Message
From: Don Dailey <[EMAIL PROTECTED]>
To: computer-go
Sent: Wednesday, June 27, 2007 1:59:12 PM
Subject: Re: [computer-go] scalability study - final results
On Wed, 2007-06
On Wed, 2007-06-27 at 10:37 -0700, terry mcintyre wrote:
> From my experience, DGS is not comparable to correspondence chess; it
> isn't anywhere near that competivive. It is generally a way to play a
> casual game over a longish period of time.
So it might be interesting to use a monte-carlo e
. They promise to be kind
masters; but they mean to be masters. -- Daniel Webster
- Original Message
From: Don Dailey <[EMAIL PROTECTED]>
To: Nick Wedd <[EMAIL PROTECTED]>
Cc: computer-go
Sent: Wednesday, June 27, 2007 10:14:49 AM
Subject: Re: [computer-go] scalability study - f
On Wed, 2007-06-27 at 17:25 +0100, Nick Wedd wrote:
> In message <[EMAIL PROTECTED]>, Don
> Dailey <[EMAIL PROTECTED]> writes
>
> >I believe humans play much stronger too at those time controls. Unless
> >of course they are playing many games and are not really focused on any
> >particular game.
In message <[EMAIL PROTECTED]>, Don
Dailey <[EMAIL PROTECTED]> writes
I believe humans play much stronger too at those time controls. Unless
of course they are playing many games and are not really focused on any
particular game.
The "unless" above is very important.
When I play on a turn-b
On Tue, 2007-06-26 at 10:45 +0900, Darren Cook wrote:
> > After throwing out the low and high ratings the top 5 players average
> > about 132 ELO per doubling and the bottom 5 average an increase of
> > about 210 per doubling.
> > ...
> > I suspect Lazarus at
> > the highest level I tested is wi
You're suggesting that it would be practically perfect with say three
more doublings (another 132*3=400 ELO points), which is "only" 32 hours
per game. At that level play should be relatively stable (statistically)
and it would be great to run just 2 games of self-play (128 hours = 5
days?), and s
> After throwing out the low and high ratings the top 5 players average
> about 132 ELO per doubling and the bottom 5 average an increase of
> about 210 per doubling.
> ...
> I suspect Lazarus at
> the highest level I tested is within a few hundred ELO points of
> perfect play. It's still a lon
On Tue, 2007-06-26 at 06:50 +0800, elife wrote:
> Hi Don,
>
> Thanks for doing this valueable work.
> Where can we get the data? I am interested with it.
>
> Cai Qiang
I put everything on that web site:
Just go to http://www.greencheeks.homelinux.org:8015/
and you can get the games from
On Mon, 2007-06-25 at 15:07 -0700, terry mcintyre wrote:
> Don,
>
> That's exciting! If Lazarus with heavy playouts can achieve "within a
> few hundred points of perfect play" on a 9x9 board, in less than 4
> hours total game time, then it should do rather well on such
> turn-based servers as the
Hi Don,
Thanks for doing this valueable work.
Where can we get the data? I am interested with it.
Cai Qiang
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Don,
That's exciting! If Lazarus with heavy playouts can achieve "within a few
hundred points of perfect play" on a 9x9 board, in less than 4 hours total game
time, then it should do rather well on such turn-based servers as the Dragon Go
Server. A 30-day clock should be more than adequate. Th
These are very interesting results. Thanks for doing all this work.
- Dave Hillis
-Original Message-
From: Don Dailey <[EMAIL PROTECTED]>
To: computer-go
Sent: Mon, 25 Jun 2007 12:34 pm
Subject: [computer-go] scalability study - final results
Someone just reminded me of the scal
Steve Uurtamo is helping me with this, he has access to several
computers he is
throwing at the study.
But another fast computer wouldn't hurt. We have to coordinate
with Steve because I don't know what he is running. If you want
to help I will send you a tarball with everything you need.
On Sat, Jan 27, 2007 at 05:13:44PM -0500, Don Dailey wrote:
> With help from other I will extend this as
> much as possible to much higher levels. Someone
> is helping me run games even now as I write
> this at higher levels - but the rate of play is
> quite slow, so it will be some time until we
On 1/29/07, Don Dailey <[EMAIL PROTECTED]> wrote:
I don't understand what you are saying here.
Here is what I THINK you are saying ...
simple MC with all as first beats "standard" UCT at
19x19 go.
Is that what you mean?
Yes, That is what I meant.
I.e. Noise is so high on 19x19, that You need
I don't understand what you are saying here.
Here is what I THINK you are saying ...
simple MC with all as first beats "standard" UCT at
19x19 go.
Is that what you mean?
My experience with simple MC is that it does beat
UCT at really fast time controls in 9x9 and I believe,
although I haven't t
Try simple MC with all as first :)
I guess it beat any UCT totally.
( one playout here will be as 200-300 in UCT)
On 1/27/07, Don Dailey <[EMAIL PROTECTED]> wrote:
Below is the current results (in progress) of my
UCT 19x19 GO scalability study.
This is going to take a lot of time, but the
resul
57 matches
Mail list logo
