Re: [computer-go] How does MC do with ladders?

> I just witnessed CrazyStone defend a fairly long ladder, resulting in > a dead 17-stone block. Why not use a ladder reader at the root of the > UCT tree to prevent provably bad ladder moves from being considered? I meant to include the CGOS-19 game number: 7613 The game is still in progress a

Re: [computer-go] How does MC do with ladders?

On Dec 11, 2007 11:36 AM, Rémi Coulom <[EMAIL PROTECTED]> wrote: > >> Question: how do MC programs perform with a long ladder on the board? > > > Crazy Stone handles ladder with progressive widening. Ladder atari is > usually ranked first or very high in the move list, and ladder extension > lower.

Re: [computer-go] Re: language efficiency

Álvaro, I'm going to take another look at alpha-beta with play-outs. I have a lot of new ideas I want to explore. - Don Álvaro Begué wrote: > > > On Dec 18, 2007 4:21 PM, Don Dailey <[EMAIL PROTECTED] > > wrote: > > > > Chris Fant wrote: > >>> I suspect that

Re: [computer-go] Re: language efficiency

On Dec 18, 2007 4:21 PM, Don Dailey <[EMAIL PROTECTED]> wrote: > > > Chris Fant wrote: > >>> I suspect that for very long time controls we would be better off > >>> turning UCT (with, say 10K playouts) into an evaluation function and > >>> then using alpha-beta on top of it. > >>> > >>> Álvaro. >

Re: [computer-go] Re: language efficiency

> I suspect that for very long time controls we would be better off > turning UCT (with, say 10K playouts) into an evaluation function and > then using alpha-beta on top of it. > > Álvaro. > I did do a study once with pure alpha beta where I used play-outs as my evaluation function. Interestingl

Re: [computer-go] Re: language efficiency

Chris Fant wrote: >>> I suspect that for very long time controls we would be better off >>> turning UCT (with, say 10K playouts) into an evaluation function and >>> then using alpha-beta on top of it. >>> >>> Álvaro. >>> >> This is very interesting to me.Not the memory management part

Re: [computer-go] Re: language efficiency

> I suspect that for very long time controls we would be better off > turning UCT (with, say 10K playouts) into an evaluation function and > then using alpha-beta on top of it. That is an interesting idea. Usually, when you have to resort to things like this it means that we need a new way of th

Re: [computer-go] Re: language efficiency

> > I suspect that for very long time controls we would be better off > > turning UCT (with, say 10K playouts) into an evaluation function and > > then using alpha-beta on top of it. > > > > Álvaro. > > This is very interesting to me.Not the memory management part, but > the fact that you beli

Re: [computer-go] Re: language efficiency

Memory is an issue with these programs, since they build tree's and > > maintain them in memory. So none of these programs can think for > more > than a few minutes per move. > > > dimwit gets around this problem by increasing the number of visits > required before a node is adde

Re: [computer-go] Re: language efficiency

Forrest Curo wrote: >> I'd like to know how well MoGo would have played if you let it think >> for a week for every move. > > Probably diminishing returns. Once a series of random playouts has > given it a selection of the more significant points to consider, I'd > expect move-order, forcing move

Re: [computer-go] Re: language efficiency

On Dec 18, 2007 3:12 PM, Don Dailey <[EMAIL PROTECTED]> wrote: > > > Harald Korneliussen wrote: > > Some thinking out loud here on the topic of languages and efficiency: > > > > I'd like to know how well MoGo would have played if you let it think > > for a week for every move. Only it seems to me

Re: [computer-go] Re: language efficiency

Forrest Curo wrote: > So Scheme is one of the languages I've been considering, and in the > process I stumbled upon a list of programs it was used to write. One of > them: GIMP (Graphic Images Manipulation Program). Relevance?--Graphic > images of any detail are enormous chunks of data; doing even

Re: [computer-go] Re: language efficiency

Harald Korneliussen wrote: > Some thinking out loud here on the topic of languages and efficiency: > > I'd like to know how well MoGo would have played if you let it think > for a week for every move. Only it seems to me that is not possible, > because I don't think MoGo will run for a week witho

Re: [computer-go] Re: language efficiency

Le mardi 18 décembre 2007, Harald Korneliussen a écrit : > Some thinking out loud here on the topic of languages and efficiency: > > I'd like to know how well MoGo would have played if you let it think > for a week for every move. Only it seems to me that is not possible, > because I don't think M

Re: [computer-go] Re: language efficiency

On Dec 18, 2007 3:03 PM, Chris Fant <[EMAIL PROTECTED]> wrote: > On Dec 18, 2007 2:21 PM, Harald Korneliussen <[EMAIL PROTECTED]> wrote: > > I'd like to know how well MoGo would have played if you let it think > > for a week for every move. Only it seems to me that is not possible, > > because I do

Re: [computer-go] Re: language efficiency

> But I have to admit, I don't know exactly how I'd go about > implementing a transposition table in Haskell :-/ Perhaps I'll try for See the Haskell implementation of my connect-4 solver, Fhourstones, at http://www.cwi.nl/~tromp/c4/fhour.html regards, -John

Re: [computer-go] Re: language efficiency

On Dec 18, 2007 3:03 PM, Chris Fant <[EMAIL PROTECTED]> wrote: > On Dec 18, 2007 2:21 PM, Harald Korneliussen <[EMAIL PROTECTED]> wrote: > > I'd like to know how well MoGo would have played if you let it think > > for a week for every move. Only it seems to me that is not possible, > > because I do

Re: [computer-go] Re: language efficiency

On Dec 18, 2007 2:21 PM, Harald Korneliussen <[EMAIL PROTECTED]> wrote: > I'd like to know how well MoGo would have played if you let it think > for a week for every move. Only it seems to me that is not possible, > because I don't think MoGo will run for a week without crashing. > Crazystone also

Re: [computer-go] Re: language efficiency

I'd like to know how well MoGo would have played if you let it think for a week for every move. Probably diminishing returns. Once a series of random playouts has given it a selection of the more significant points to consider, I'd expect move-order, forcing moves, the need to follow a seque

[computer-go] Re: language efficiency

Some thinking out loud here on the topic of languages and efficiency: I'd like to know how well MoGo would have played if you let it think for a week for every move. Only it seems to me that is not possible, because I don't think MoGo will run for a week without crashing. Crazystone also crashes q