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

[David G Doshay <ddoshay@xxxxxxx>]

On 10, Feb 2005, at 3:26 PM, Don Dailey wrote:

> If the time control were to
> suddenly change, then if SlugGo actually does have an edge as believed
> by the authors, then that advantage might go away.
Yes, it surely might. And it is for exactly that reason that I think it
sensible to open up the subject of whether *all* computer Go
tournaments should be played with a one hour limit. Human
tournaments clearly are not.

I honestly do not care if SlugGo happens to win a tournament or
not. It would be fun, but largely irrelevant. I simply want to know
what ideas are required to get Go programs to play better, and
right now I am willing to apply a large number of CPUs to the
task. Lots of CPUs today is much the same as a common desktop
computer in 5 or 10 years. I'd rather do my development and
testing of ideas now rather than wait.

> Every tournaments has rules and they are not necessary "artifical" or
> impose "limitation" because they are not convienent for me or you.
I still see this kind of a time limit as artificial.  It has nothing to 
do with
my personal convenience because I already have worked out my
solution to the fact that computers are not already faster than they
are today ... I use lots of them and I run my games when I am doing
other things so I don't have to watch how slow they are.

Just for perspective, physics simulations I have done in the past
took a month of 24x7 run time to generate their data and another
month of 24x7 run time to reduce that data down to a single
number. I seem to spend my efforts out at the edge of what people
are willing to wait for computers to do.

>  In my view, your programming system for Go is the one with limitations
> (which it should be possible to overcome if the idea is valid.)
Indeed, the chosen architecture for SlugGo is a limitation of sorts.
It was chosen to optimize one particular aspect of computation:
when I have a new thread to investigate I want a CPU to be ready
to work exclusively on that problem.  And yes, SlugGo would be
MUCH faster if I had access to the internal data in Many Faces of
Go rather than GNU Go. MFoG is much faster than GNU Go. But
one is open source and the other is not, so the open source option
is the only one I can use. I cannot know if using MFoG would be
stronger or not. I am willing to get together with David Fotland to
find out, if he thinks it is worth his time and is willing to let us see
his internals. I am an independent academic and really only
care about the ideas.

But it remains a simple fact that the whole board look ahead that
SlugGo does requires the serial generation of moves out to the
look ahead depth. That cannot be sped up. The lookahead depth
can be trimmed, but we have the data that shows shorter lookahead
is not as strong.


Cheers,
David


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