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 logg
>>> ... 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
http://www.lri.fr/~gelly/Publications.htm
On 1/24/08, Christoph Birk <[EMAIL PROTECTED]> wrote:
> On Sun, 13 Jan 2008, Sylvain Gelly wrote:
> Google finds it:
> http://tao.lri.fr/Papers/thesesTAO/SylvainGellyThesis.pdf
> >>
> > That is NOT the latest version. Please at least let me put t
On Wed, 2008-01-23 at 18:57 -0500, Eric Boesch wrote:
> I am curious if any of those of you who have heavy-playout programs
> would find a benefit from the following modification:
>
> > exp_param = sqrt(0.2); // sqrt(2) times the original parameter value.
> > uct = exp_param * sqrt( log(sum o
On Jan 23, 2008 3:11 AM, Hiroshi Yamashita <[EMAIL PROTECTED]> wrote:
> 2. Change UCT exploration parameter
> exp_param = sqrt(2.0);
> uct = exp_param * sqrt( log(sum of all children playout) /
> (number of child playout) );
> uct_value = (child winning rate) + uct;
>
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 logged on and won't let them log back on.
So until I find the bug, the server
On Sun, 13 Jan 2008, Sylvain Gelly wrote:
Google finds it:
http://tao.lri.fr/Papers/thesesTAO/SylvainGellyThesis.pdf
That is NOT the latest version. Please at least let me put the latest
version on my web site, it took me so long to correct it :).
Where may we find the latest version?
Chris
Maybe it's just a temporary thing, but I just happened to check and CGOS was
down... I get lots of messages like the following:
22:43:00Server startup return code: 1 msg: couldn't open socket:
connection refused
22:43:00Cannot connect to server. Will retry shortly
_
I gave you a proof of what I am claiming, I really dont see what I can do more.
Anyway we all now all this is just a waste of time for pleasure. People who are
really working on a UCT engine (I dont anymore) will find solutions to these
problems as soon as they become relevant to playing strength
i.e.,
any case where discovering a particular position
would require making illegal moves during that
playout with respect to the move policy in place.
so for instance, if the only way to discover the death of a
group is to play inside one-point eyes, and there's a playout
policy that says to nev
ivan dubois wrote:
Hello,
- Message d'origine
De : Michael Williams <[EMAIL PROTECTED]>
À : computer-go
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
ivan dubois wrote:
I agree t
By the way, my argument still applies when there are no outside liberties,
because the eye filing itself is a long enough UCT "trap" (a sequence of moves
that appears to be just like null moves).
I gave a theoretical argument, but actualy it is not very surprising. Did you
ever wonder why Mogo
Hello,
- Message d'origine
De : Michael Williams <[EMAIL PROTECTED]>
À : computer-go
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
ivan dubois wrote:
> I agree that the current imp
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
I think many of you miss the point completely about the scalability issue.
You can ALWAYS construct a situations where leaf node evaluation is
wrong or where it will take an arbitrary number of play to solve a
particular problem. In chess it is possible to construct problems
that cannot be so
ivan dubois wrote:
I agree that the current implementation of Mogo (from what I know about
it) will not know for sure that the D17 black group is 100% dead.
It will think that it is X% dead and stick to that estimation, whatever
thinking time you give it. X is a constant that does not depend o
Joel Veness wrote:
> Hi Ivan,
>
> I like to view game tree search methods as a systematic ways to
> correct static evaluation errors. I don't find it surprising that UCT
> scales well with increasing time and space. I claim that the accuracy
> of the monte-carlo method increases as we get closer
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> >Sure, 9x9 Go is still a very interesting game. One that can be a
> >challenge even for the strongest players in the world. But in my
> >opinion it's not nearly as interesting as 19x19 Go. Now if that's a
> >point you'd like to argue, fine. But no n
Thanks.
- Message d'origine
De : Russell Wallace <[EMAIL PROTECTED]>
À : computer-go
Envoyé le : Mercredi, 23 Janvier 2008, 18h07mn 27s
Objet : Re: Re : Re : [computer-go] Is MC-UCT really scalable ... is a troll
On Jan 23, 2008 3:44 AM, Don Dailey <[EMAIL PROTECTED]> wrote:
> This is s
On Jan 23, 2008 3:44 AM, Don Dailey <[EMAIL PROTECTED]> wrote:
> This is still nonsense. UCT in actual real world "PRACTICE" responds
> dramatically to more hardware, how can you say it's not clear whether
> it's scalable in practice?
In fairness, he didn't say that. What he said was that our b
I disagree. If the opponent's estimate of the rest of the board is at least as
good as program XXX, but the opponent knows a particular group is 100% dead,
where program XXX thinks it might live, the opponent is likely to win, with a
probability approaching 1.00. Program XXX will be basing its d
Hi,
This is correct.
Do you think there will be no playouts where the group dies ?
I think there will be around 50% where the group dies. If you think this is not
the case, please explain to me.
Ivan
- Message d'origine
De : steve uurtamo <[EMAIL PROTECTED]>
À : computer-go
Envoyé
Quoting terry mcintyre <[EMAIL PROTECTED]>:
Filling suc an eye does not require an "extremely strong" opponent;
I am rated a mere 9 kyu AGA, and use this method often.
My opponents also use it every chance they get. When teaching 20 kyu
players, these known-dead shapes are right at the top
On Jan 22, 2008, at 2:08 PM, [EMAIL PROTECTED] wrote:
MoGo plays unconventional moves only in the first 10 moves or so.
That is it plays an unconventional openning. An unconventional
opening in Go is actaully something that is celebrated for ...
DL
If this is a concern, someone should ad
it will only assign it a positive probability of being
dead if there are playouts where the group dies, right?
s.
- Original Message
From: ivan dubois <[EMAIL PROTECTED]>
To: computer-go
Sent: Wednesday, January 23, 2008 10:51:52 AM
Subject: Re : [computer-go] Bent four in the
Hello,
I agree that the current implementation of Mogo (from what I know about it)
will not know for sure that the D17 black group is 100% dead.
It will think that it is X% dead and stick to that estimation, whatever
thinking time you give it. X is a constant that does not depend of thinking
Filling suc an eye does not require an "extremely strong" opponent; I am rated
a mere 9 kyu AGA, and use this method often.
My opponents also use it every chance they get. When teaching 20 kyu players,
these known-dead shapes are right at the top of the list.
However, several otherwise strong
Feed any MC-UCT program the position after White B1, at move 195, and ask the
probability of a black win. Repeat until the program corrects its estimate.
It would be interesting to determine just how many simulations are needed to
solve this problem - which is obvious to double-digit kyu players
Hello,
After thinking a bit more about it, I came to the conclusion that the so called
"Bent four in the corner" shape, is not such a serious scalability killer (I
like this term).
Nor is the situation that appears in your game.
Let me explain why :
It would indeed be a scalability killer i
From: Harald Korneliussen <[EMAIL PROTECTED]>
>I recalled a KGS game of Mogo I'd looked at, where something very similar
>happened, and with a little digging I found it again:
> http://files.gokgs.com/games/2007/12/1/Ardalan-MoGoBot3.sgf
Thanks for the example! That's the infamous "square four"
On Wed, 23 Jan 2008, Harald Korneliussen wrote:
> It turns out it's not the "bent four" shape, but I suspect it's
> another such shape, where more playouts only confirm that "these moves
> aren't worth including into the tree", so that UCT catches them very
> late, if ever.
Just a quick note tha
Ok, this is a "special" minimax solver. Call it the "Ivan Dubois stupid minimax
solver" if you like.
Anyway, its only purpose is to show that :
"Returns the best move when given enough time" does NOT implie "Is scalable
in practice".
I am very sad that this simple logic has no appeal to mo
Ivan Dubois mentioned the bent four in the corner shape as a
scalability killer, a situation where more playouts doesn't help
(much), because playouts systematically misevaluate it. As I
understand it, it could be corrected in the tree, but this is very
unlikely to happen until the very end of a g
On Jan 23, 2008 2:45 PM, ivan dubois <[EMAIL PROTECTED]> wrote:
> When I say a minimax solver, I mean a program witch returns a random move
> UNTIL it has completed its search, as I explained in a previous post.
A plain minimax solver (without enhancements like iterative deepening)
doesn't return
Duhhh !
When I say a minimax solver, I mean a program witch returns a random move UNTIL
it has completed its search, as I explained in a previous post. You all agreed
this program didnt scale, so why are you saying, all of a sudden, that it DOES
scale now !?
Anyway I'm fed up with this discuss
On Jan 23, 2008 1:47 PM, Jacques Basaldúa <[EMAIL PROTECTED]> wrote:
> Erik van der Werf wrote:
>
> > You may also be interested in my
> > article on estimating potential territory
>
> I am. Can you post a link, please.
sure, it's all at:
http://erikvanderwerf.tengen.nl/publications.html
My thes
I don't think "only uniformly random playouts will scale to
perfection" because what we need for playouts is not just a simple
average of final scores but a maximum (in negmax sense) score. It
should be the perfect evaluation function.
In other words, as MC simulation is a way to get an avera
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
Erik van der Werf wrote:
You may also be interested in my
article on estimating potential territory
I am. Can you post a link, please.
Jacques.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/co
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
Quoting Heikki Levanto <[EMAIL PROTECTED]>:
But you still prune moves like filling a one-point eye. We know that there is
a pthological case where that indeed is a correct move. So Valkyria will
never converge to perfect play even with unlimited CPU power.
Yes, this is a known bug. :)
But, I
On Wed, Jan 23, 2008 at 11:18:37AM +0100, Magnus Persson wrote:
> Indeed, Valkyria, uses the same code to prune move in both the
> playouts and in the UCT-tree. This pruning is supposed to be 100% safe
> and applies to really bad and ugly moves.
But you still prune moves like filling a one-po
Quoting Heikki Levanto <[EMAIL PROTECTED]>:
I agree on this _only_ if the UCT check all possible moves.
If not one can be limited by the quality of the playout.
I think we may be confusing two different things here:
a) Using all "possible" moves in the playouts to evaluate a leaf in
t
On Tue, Jan 22, 2008 at 05:17:48PM -0500, [EMAIL PROTECTED] wrote:
>
> Don't make too much of it. A 2-Dan program will play 2-Dan games, not just
> occasionally generate a 2-Dan move. :)
True. Most weak beginners start the game with a move that is often seen in
professional play. Usually 3-3, 3-
On Tue, Jan 22, 2008 at 09:51:11PM +0100, 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
Congratulations! I'm really impressed with how fast the AyaMC improved.
Regards,
David
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:computer-go-
> [EMAIL PROTECTED] On Behalf Of Hiroshi Yamashita
> Sent: Wednesday, January 23, 2008 12:12 AM
> To: computer-go
> Subject: [comput
Le mercredi 23 janvier 2008, ivan dubois a écrit :
> Hi Alain,
> Sorry for being so insistant :
You should browse the archive of the list, nearly the same discussion about
infinite and scalability happenned in 2007.
>
> >No i just said that, unless i really understood nothing, i read here from
My program Aya637_4CPU is top on 19x19 CGOS now.
It is temporary, but I'm so happy!
Please don't run full power MoGo, Crazy Stone and Leela :-)
My main improvement was
1. Do not move dead stones.
Before doing playout, Aya does string capture search up to 7 plies(ladders
are extended). And set th
51 matches
Mail list logo
