[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [computer-go] how to use GTP in place of GMP
The commercial programs all struggled to complete a tournament game in the 1
hour time limit.
Most of the commercial programs were written back in the days of the Ing
contest with the
$1 Million prize. A program that completed all it's moves in an hour back
then on a 166 MHz
Pentium will seem very fast today. I don't know anyone who is trying to
make a program
move in less than a second. My tactician was designed to answer all the
interesting tactical
questions in one hour per game, on a 66 MHz computer. I don't see any need
to recode it to
run slower now :) The strategic questions can't be solved by any amount of
search. I would use
more time if I knew how to use it to make the program stronger.
If I use the extra time to do extra searching on moves that the programs
knows are stretegically
weak, there is a chance that some anomaly in the evaluation or the search
will pick a worse move.
Can your program beat Many Faces of Go with a 1000 to 1 time advantage on a
19 line board?
Regards,
David
> -----Original Message-----
> From: computer-go-bounces@xxxxxxxxxxxxxxxxx
> [mailto:computer-go-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Don Dailey
> Sent: Friday, August 13, 2004 7:18 PM
> To: computer-go@xxxxxxxxxxxxxxxxx
> Cc: computer-go@xxxxxxxxxxxxxxxxx
> Subject: Re: [computer-go] how to use GTP in place of GMP
>
>
>
> Hi David,
>
> I agree, playing well should be the goal. Computer Go has always
> seemed odd to me because it seems like all the programs are
> fixed up to play really quickly. Everyone complains how
> abouot how much they stink, but they whip out moves
> instantly, almost as if they know all they need to know to
> play a move.
>
> There is a different mentality about this than in
> computer chess, probably because computer chess responds
> very naturally to a highly scalable algorithm (called global search.)
>
> So if your program plays just slightly better than mine,
> but yours takes 100 times longer to compute, is your program
> really better? In computer chess the answer is no, but in
> computer go the answer seems to be YES.
>
> My program takes a very long to play a good move (good
> being a relative term of course :-) It's very scalable, so
> I can lose to any program and beat any program if we can
> simply ignore the clock.
>
> Go programs care a lot about time, but it seems to be
> only in the sense that it is a sin to take more than a
> second to move.
>
> Of course I'm not familiar with all programs. I am curious
> about the commercial programs, do they all play "hair on
> fire" speed go?
>
> - Don
>
>
>
> Programs are already disqualified for being slow: it is
> now the norm
> that
> a program must play a game in an hour and I cannot get my
> code to do
> that even though I run on a cluster of very fast CPUs. So
> at this time I
> cannot participate in any competition. But given the
> present paranoid
> climate, I cannot compete anyway because I am not even going to
> consider packing up my cluster for transport to a
> tournament site. The
> only solution I can think of is to host a tournament at my site.
>
> With the present state of Go programming I think that just
> being able to
> play well should be the goal, not to play well and fast,
> but that is
> just me.
>
> I view the biggest security issue to be sneak attacks on the other
> computer.
> For this a referee program in the middle to inspect and buffer the
> communication
> stream seems like the best idea. Our group has just
> (today) started on
> such a program. If it proves of interest, and I imagine it
> might given
> the
> volume of email on these subjects the last few days, we
> will gladly make
> our code available in the normal GNU public license sense.
>
> Cheers,
> David
>
>
> On Aug 13, 2004, at 2:39 PM, Richard Brown wrote:
>
> > William Harold Newman wrote:
> >
> >> Another possibility, perhaps only marginally practical now,
> >> but probably more practical in ten years, might be to
> play games with
> >> an average time allowance so short (perhaps 250
> milliseconds per move?
> >> 150?) that humans can't react fast enough to be helpful.
> >
> > Hmmm. Not merely impractical, but highly unfair to my program,
> > which has to do some disk access, because the pattern database is
> > too large to fit into memory. That disk access makes my program
> > slow, and your proposal punishes me for that.
> >
> > Is such a program to be disqualified, just because it's "slow"
> > in your opinion?
>
> _______________________________________________
> computer-go mailing list
> computer-go@xxxxxxxxxxxxxxxxx
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
> _______________________________________________
> computer-go mailing list
> computer-go@xxxxxxxxxxxxxxxxx
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/