David Fotland wrote:
Mogo and Mark create a new node for
each new simulation.
I think MoGo creates child nodes only after the parent has accumulated 5
simulations. You can also change that number with a command-line parameter.
___
computer-go
Good point. But he is talking about far more games than would be available
with that method.
Darren Cook wrote:
Unfortunately, I used level 10 in the gnugo only games but in the big
study we use level 8. ...
... it's a major pain running those games and it ties up my
machine.
Hi Don,
I
David Fotland wrote:
Since you hijacked my thread, I'm changing the title and injecting some data
:)
I tried to be very clear that I didn't want that thread to become another
scalability flame fest.
Here is a high level mogo game, level 15 vs level 16, that hinges on a life
and death problem
I think we would all agree that UCT+MC is quite good for strategy but not so good with tactics. I'd like to see this hybrid engine: One that starts with a
traditional full-board static analysis (with local tactical searches), looking for urgent moves. If it finds an urgent move, it makes it.
tactical
smarts to playouts. If there's a pre-existing nakade, seki, etc, the
playouts should get it right.
On Feb 1, 2008 10:34 AM, Michael Williams [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I think we would all agree that UCT+MC is quite good for strategy
but not so good with tactics
Any chance of adding a new column to the CGOS result tables to show the average
amount of time used per game?
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
of the study I would
have to get them to update again - probably a lot of hassle.
Perhaps I will make the next test handle this.
- Don
Michael Williams wrote:
Any chance of adding a new column to the CGOS result tables to show
the average amount of time used per game
Don, welcome to my battle last week (or was it the week before?). It was the exact same discussion. I don't know if people are assuming that a typical UCT
reference implementation does not consider all moves or if they just don't understand the difference between a playout policy and a tree
Are you kidding? That's based on only 10 games.
Hideki Kato wrote:
Don Dailey: [EMAIL PROTECTED]:
About Don's arguments on self testing:
I would agree at 100% if it wasn't for the known limitations:
Nakade, not filling own eyes, etc. Because the program is blind
to them it is blind in both
He stated that there is a depth limit in FatMan. IMO, it is quite likely that
is the limiting factor.
Jeff Nowakowski wrote:
On Tue, 2008-01-29 at 17:41 -0500, Don Dailey wrote:
This is in response to a few posts about the self-test effect in ELO
rating tests.
[...]
So my assertion is
I don't feel like searching for it right now, but not too long ago someone posted a link to a chart that gave the winrates and equivalent rankings for different
rating systems.
Don Dailey wrote:
I wish I knew how that translates to win expectancy (ELO rating.)Is
3 kyu at this level a
ivan dubois wrote:
Hello,
- Message d'origine
De : Michael Williams [EMAIL PROTECTED]
À : computer-go computer-go@computer-go.org
Envoyé le : Mercredi, 23 Janvier 2008, 20h38mn 32s
Objet : Re: Re : [computer-go] Bent four in the corner was:Scalability problem
of play-out policies
Just allow any login to superceed any previous login.
Don Dailey wrote:
I am in the process of restarting it and you just happened to be there.
There is still a bug in the server where occasionally the server will
not realize a bot disconnected. In those cases it thinks they are
still
... perhaps only uniformly random playouts
will scale to perfection.
The reason that MC/UCT scales to perfection is because of the UCT part, not the
MC (playout) part. People seems to forget this a lot.
___
computer-go mailing list
Playouts can limit scalability.
No, I don't think so.
I asked recently about Mogo not being able to detect that four liberties
in a square do not two eyes make. The only explanation offered was that the Mogo playouts rejected
the possibility of a move inside the eyespace; this skewed the UCT
Alain Baeckeroot wrote:
Le mardi 22 janvier 2008, Michael Williams a écrit :
... perhaps only uniformly random playouts
will scale to perfection.
The reason that MC/UCT scales to perfection is because of the UCT part,
not the MC (playout) part. People seems to forget this a lot.
I agree
Exactly! Well said.
Weston Markham wrote:
(I typed the following up earlier today, before other people cast some
doubts about what infinite scalability means. Perhaps it is
helpful.)
I think that Alain was specifically referring to a property of UCT,
whereby given that a winning line of play
It seems like our CPU cyces would be better used testing even higher levels of MoGo than the current levels of Fatman. MoGo appears to be at least an order of
magnitude more efficient.
___
computer-go mailing list
computer-go@computer-go.org
I agree. I see no reason to discard the mogo vs fatman games when mogo moves
to higher levels. Just add to the current database, as is.
Christoph Birk wrote:
On Jan 21, 2008, at 5:50 PM, Don Dailey wrote:
When this test is completed, let's use the infrastructure I created
here to run a
not be quite as efficient.
Olivier seemed to think it would work acceptably well.
- Don
Michael Williams wrote:
Also, with the parameters you are using for MoGo, I think the tree
will stop growing at 100k nodes, which doesn't take very long to get to.
Don Dailey wrote:
I wish I had named
Would be cool if you could somehow also show the average memory footprint and
time used at each doubling for each program.
Don Dailey wrote:
I wish I had named the weakest players _00 instead of _01 and expressed
everything as you are suggesting, it would indeed be clearer.
I could
Also, with the parameters you are using for MoGo, I think the tree will stop
growing at 100k nodes, which doesn't take very long to get to.
Don Dailey wrote:
I wish I had named the weakest players _00 instead of _01 and expressed
everything as you are suggesting, it would indeed be clearer.
hard to tune. A lot of games of my engine are lost due
to completely insane self-atari moves in the early games. Even I have
policy to disfavor the self-atari moves, those moves just keep surfacing
out.
On Jan 18, 2008 9:28 AM, Michael Williams [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote
An alternative to matching board hashes is to test for repeated move sequences. You need a separate test for each sequence length, but the most common one
should be the shortest one.
Heikki Levanto wrote:
On Thu, Jan 17, 2008 at 10:36:09PM -0500, Michael Williams wrote:
I have not tried
Yes. Please reread compgo123's message.
Song wrote:
I learned many things, thank you very much.
I want to know one more thing.
If the GO rules standardized on one ruleset that forbid suicide,
At that time, do you still disscuss suicide and use it in game evaluation ?
Song
[EMAIL
I was doing a small scalability test own my own with mogo on 7x7 with 8.5 komi and so far the most interesting game is mogo losing as back given 64 seconds per
move against a white player using 32 seconds per move. With this komi, black is currently winning 72% of the games (with player
]
To: computer-go computer-go@computer-go.org
Sent: Thursday, January 17, 2008 10:11:14 AM
Subject: Re: [computer-go] Suicide question
Michael Williams wrote:
It is a very nice graph. I wish we could see the next 11 doublings.
With some help, I could redo this experiment and add:
1 or 2 more
Thank you. I've been waiting for your release that you said you would do a
while back. Hopefully I can get some time to look at it next week.
Jason House wrote:
On Jan 1, 2008 9:27 PM, Jason House [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I've started an open source
.
So do we also can consider of ignore KO's rule when doing game evaluation
(play-out simulation) ?
Michael Williams [EMAIL PROTECTED] wrote:
Yes. Please reread compgo123's message.
Song wrote:
I learned many things, thank you very much.
I want to know one more thing.
If the GO rules
Don Dailey wrote:
Mark,
I wasn't stating a precise value for a doubling when I said 100 ELO.
But it appears that it is actually worth a bit more than 100 ELO for a
doubling.I did a massive study of this at one point a year or
more ago with thousands of games with UCT based Lazarus
the number of doublings and ELO ratings are on the
Y axis.
- Don
Michael Williams wrote:
Don Dailey wrote:
Mark,
I wasn't stating a precise value for a doubling when I said 100
ELO.But it appears that it is actually worth a bit more than 100
ELO for a
doubling.I did a massive
Sylvain Gelly wrote:
It looks like MoGo does respect the time_left commands from GTP, so I
don't think the totalTime parameter is required in this case.
What do you mean? If you don't put --totalTime, then MoGo indeed ignores
time_left. If you put --totalTime, then it respect the
There is lots of English in it. Just scroll down.
terry mcintyre wrote:
From: Rémi Coulom [EMAIL PROTECTED]
Sylvain Gelly wrote:
Yes I did! :).It is not on my website, but will (soon?).
However, you should not be so eager to read it :)
Cheers,
Sylvain
Google finds it:
Sylvain Gelly wrote:
The reason I said that was this behavior from mogo. If I start it
without that switch and as for a move, it allocates 20 seconds. If
I then issue a small
time_left command and ask for another move, it allocates a much
smaller amount of time. Here is
you told him to set
his parameters for a 19x19, by default the boardsize is 9x9 and MoGo
expects a gtp command to override it.
Cheers,
Sylvain
2008/1/13, Michael Williams [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Sylvain Gelly wrote:
The reason I said
Gian-Carlo Pascutto wrote:
Olivier Teytaud wrote:
Also, there are probably other people interested in combining
UCT and mpi; I don't know if some people have a more precise idea
of the level of the MPI+UCT combination than us. Someone ?
MPI is just a parallel programming model/library,
So what? That is not relevant, as long as the algorithm is still
UCT-like even when parallelized, so that Don's scaling research holds.
How they parallelize is completely irrelevant as long as they measure
effective speedup, i.e. time to find the best move. There is absolutely
no requirement
I don't know about everyone else, but I would like to see the programs
displayed in rank order even if they are not totally stable yet.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Don Dailey wrote:
Take a look at the 9x9 web page now.
- Don
I think it looks great. Thanks, Don.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Lardo1 crashed or something else happed that caused the cgos client
script to fail. Anyway, I probably won't put it back up. I think it's
too weak to be of any use.
___
computer-go mailing list
computer-go@computer-go.org
I think I found one source of CGOS lockups. In
cgos.vfs/lib/app-cgos/cgos.tcl, the following code exists:
proc send {sock msg} {
if { [catch { puts $sock $msg }] } {
set who $id($sock)
log alert: Socket crash for user: $who
}
}
But when the third line down fails, cgos
MoGoRel3_3550pps is MoGo started like this: ./mogo --19 on a core2
duo, which is yielding about 3550 playouts per second from an empty
19x19 board. Does the current rating of 1143 seem lower than expected
to anyone else? I guess the public version of MoGo was designed with a
focus on 9x9 and
--playsAgainstHuman 0
for mogo-pr-10k on cgos 9x9.
I guess --playsAgainstHuman 0 is missing.
-Hideki
Michael Williams: [EMAIL PROTECTED]:
MoGoRel3_3550pps is MoGo started like this: ./mogo --19 on a core2
duo, which is yielding about 3550 playouts per second from an empty
19x19 board. Does
Is anyone altering the playout policy during the course of a game? Is
seems like a huge potential win if done right (of course, I don't claim
to know how to do it right). If so, can you give any details?
___
computer-go mailing list
Yes, Largo. I have a version of this I can put on CGOS (and other's can
too so that we can check each other for bugs). I tried using Largo as a
component of a playout policy with no success.
I will also put a version of MoGo up (the version that was released to
the public).
David Fotland
Is it true that the compiled cgos clients will not work for 19x19
because they do not accept a server and port as parameters? Could these
parameters be added and the binaries recompiled?
___
computer-go mailing list
computer-go@computer-go.org
I followed the instructions at
http://www.mail-archive.com/computer-go@computer-go.org/msg04946.html
and it appears that Largo connects (saw it in cgosview), but there is
some problem. I get zero feedback in the dos window that I start the
tcl script. Any ideas?
Don Dailey wrote:
Michael Williams wrote:
Yes, it's mine. It was me accidentally swapping Largo/Lardo again.
Does Largo try to do what my Lardo used to do, play according to Doug
Larsens rules?
Yes. But like I said, I never meant to call it Largo. You will not see
Largo logged in again
Can anyone point me to a move in a 19x19 game that is commonly seen as
the best move but hard to find? I know of the Ear Reddening move, but I
don't know whether or not that meets my criteria (I'm not a dan player,
or even close). Thanks.
___
201 - 249 of 249 matches
Mail list logo
