[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [computer-go] Computer Go tournament at EGF

On 10, Feb 2005, at 2:18 PM, Arend Bayer wrote:


On Thu, 10 Feb 2005, David G Doshay wrote:


It seems from the set of replies that computer Go wishes to retain
what I see an an artificial but generally accepted limitation of one
hour per program, with possible exceptions in some tournaments
which allow for byo-yomi.
This limit is not artificial. There may be programmers who are developing
go programs with actual users in mind :) I am pretty sure that most users
will want the program to think rather half an hour than an hour per game.
I agree that people playing against a computer have a high probability
of wanting the computer to play in under an hour. I even feel the same
myself and this is the reason I have only played against SlugGo twice.
It is hard for me to find a block of time to play a several hour game and
I play slowly too.


As above, I have figured out a way to force SlugGo to play faster
and it is likely that the effect upon playing strength will be that it
plays weaker. I have seen enough SlugGo games to be sure that
it will play differently.



Well, you are only lacking a factor of 3 :)




A complete rewrite of the code did bring it down from 5, but 
restructuring

will not get another similar factor.




Did you try running GNU Go at lower levels?



Yes, we tried 5 and 8 and it played distinctly worse. We are using level
10.




Are you trying some early cutoffs of the parallel
search, in case the valuations of the end positions yields big
difference already for smaller depths?



We only evaluate at the end of the lookahead, so we do not have
this information earlier.




GNU Go's persistent caches might be used inefficiently in your setup.
(The purging assumes there is no undoing of several moves as
happens in your case after the SlugGo search for one move is finished.)



We have considered that we are not taking advantage of GNU Go's
persistent caches, but a few quick experiments did not show significant
speed improvement from when we tried to start fresh at each look ahead
choice. This is something we should investigate deeper. We are slowly
learning GNU Go internals.




Finally, there is still the project of parallelizing each instance of
GNU Go across the cluster...



This is something that I do not feel qualified to attempt. My earlier
offer of cluster time to the GNU Go team is still open.

Cheers,
David


_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/