[computer-go] Re: language efficiency

2007-12-19 Thread John Tromp
On Dec 19, 2007 1:00 PM, Jeff Nowakowski <[EMAIL PROTECTED]> wrote: > On Tue, 2007-12-18 at 15:04 -0500, John Tromp wrote: > > > > See the Haskell implementation of my connect-4 solver, Fhourstones, at > > http://www.cwi.nl/~tromp/c4/fhour.html > > You say on that page: "On my machine, the Java v

Re: [computer-go] Re: language efficiency

2007-12-18 Thread Don Dailey
Á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

2007-12-18 Thread Álvaro Begué
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

2007-12-18 Thread Don Dailey
> 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

2007-12-18 Thread Don Dailey
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

2007-12-18 Thread Don Dailey
> 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

2007-12-18 Thread Chris Fant
> > 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

2007-12-18 Thread Don Dailey
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

2007-12-18 Thread Don Dailey
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

2007-12-18 Thread Álvaro Begué
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

2007-12-18 Thread Gunnar Farnebäck
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

2007-12-18 Thread Don Dailey
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

2007-12-18 Thread Alain Baeckeroot
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

2007-12-18 Thread John Tromp
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

2007-12-18 Thread John Tromp
> 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

2007-12-18 Thread Chris Fant
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

2007-12-18 Thread Chris Fant
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

2007-12-18 Thread Forrest Curo
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

2007-12-18 Thread Harald Korneliussen
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

[computer-go] Re: Language

2007-11-14 Thread Dave Dyer
>It appears that the question of GC is not dependent on the problem >(eg. computer-Go) but on the language you use. This really gets back to the core of the language question. The kind of language you choose depends in part on the kind of program you intend to write. If you're writing a monte c

[computer-go] Re: Language

2007-11-14 Thread Dave Dyer
>It appears that the question of GC is not dependent on the problem >(eg. computer-Go) but on the language you use. This really gets back to the core of the language question. The kind of language you choose depends in part on the kind of program you intend to write. If you're writing a monte c

Re: [computer-go] Re: language choices

2006-12-06 Thread Stefan Nobis
Antoine de Maricourt <[EMAIL PROTECTED]> writes: > I can develop very quickly 'quick and dirty' code to test new ideas > in C++, and recode it in a very clean / organized / modular / robust > ... code later if needed. This ability is not coming from the > programming langage itself... I beg to di

Re: [computer-go] Re: language choices

2006-12-05 Thread Antoine de Maricourt
But as a chess programmer, I disagree with your statement about orders of magnitude. If your chess program is 30% faster than mine, all else being equal, you have a measurably stronger chess program and you will probably win even a fairly short match. In a highly competitive chess tourname

Re: [computer-go] Re: language choices

2006-12-04 Thread Don Dailey
On Mon, 2006-12-04 at 12:15 -0800, Dave Dyer wrote: > Guys, keep your eyes on the prize. If your only problem > is that you need to double your speed, all you have to do > is wait 1.5 years. > > All this talk of optimizing speed by tweaking language xx to be > more like assembly language (or C)

[computer-go] Re: language choices

2006-12-04 Thread Dave Dyer
Guys, keep your eyes on the prize. If your only problem is that you need to double your speed, all you have to do is wait 1.5 years. All this talk of optimizing speed by tweaking language xx to be more like assembly language (or C) is almost completely a waste of time. Likewise, algoritmic opt