Re: [computer-go] blitz computer go (Re: Computer Go tournament atEGF)

[Don Dailey <drd@xxxxxxx>]

Yes, the idea of being able to build up a time budget probably is best
as there is some forgiveness in the system.  It's possible to defeat
the system, but at great effort and risk of actually hurting the
program.   

There should be some feedback to the program, so that the program has
the option to make its own time budget considerations.  It would be
easy to send timing information with each move for instance.


- Don






   X-Original-To: computer-go@xxxxxxxxxxxxxxxxx
   Date: Fri, 11 Feb 2005 15:24:43 -0600
   From: William Harold Newman <william.newman@xxxxxxxxxxxxxxxxx>
   Content-Disposition: inline
   Reply-To: computer-go <computer-go@xxxxxxxxxxxxxxxxx>
   Sender: computer-go-bounces@xxxxxxxxxxxxxxxxx
   X-Spam-Score: -5.811
   X-Spam-Flag: NO
   X-Scanned-By: MIMEDefang 2.42

   On Fri, Feb 11, 2005 at 12:15:24PM -0500, Don Dailey wrote:
   > >   I think its a great idea.  I would participate in an internet
   > >   superblitz for sure (given enough warning to implement the chosen
   > >   protocol).  In order to not allow cheating by no-client-response
   > >   followed by "I lost my connection for a little while", you would just
   > >   have to have no exceptions to the 1-second rule (or whatever) and make
   > >   up for lost connections by playing multiple games, as you suggest.
   > 
   > I like this too but it seems almost unworkable since most internet
   > connections, even good ones, have some intermittent lags.  I don't
   > think the multiple game idea works, you could arrange to "lose your
   > connection" when your program finds itself in a lost game!

   The way I wrote it, I can understand why people thought that I meant
   no more than x time for any single move, so that any single move which
   used, e.g., 1.3x would lose. However, what I actually had in mind was a
   running total time of x per move, where you get to save the extra for
   future moves, so that if you play a sequence of moves in
     0.8x, 0.9x, 0.8x, 0.8x, 0.9x, 0.8x, 0.8x, 1.2x, 0.9x, ...
   you are still OK, despite the 1.2x anomaly in there. (I started with
   the idea of a minute or two total per game, and then backed off to a
   per-move time allowance because I didn't want to encourage programs
   trying to win by playing more moves per game than the opponent
   expected.) I think this approach of accumulating excess 
   would still make it pretty hard for a human to provide much useful
   input, while being much less vulnerable to modest amounts of lag.
   (Other schemes with similar tradeoffs are also possible: e.g.,
   as many as 6 moves with single move delay <=3x are permitted, but
   the rest must all be made with single move delay <=1x; or total
   time overrun over the entire game is bounded by 5x.)

   I would expect that on any Internet link clean enough that you can use
   it to carry a telephone conversation for two minutes with N% chance of
   avoiding noticeable glitches, you could play a game with x = running
   average of 0.5sec with somewhat more than N% chance of success. It's
   my impression that links with N>=95 are, if not exactly common today,
   at least not vanishingly rare. I expect even in a strange city I could
   find such a connection to elsewhere in the USA, if necessary by
   schlepping my laptop to someplace where twitch gamers hook up. (IIRC
   tolerable telephony delays are on the order of 0.3sec, while gamers
   get irritated with somewhat less than that, and AFAIK gamers'
   attention span hasn't fallen below 2 minutes yet.)

   > Even computers with sophisticated operating systems can "go south" for
   > a brief period of time doing disk access/bookeeping, running brief
   > system daemons, etc.

   True. I've even run into this from time to time, most recently when
   doing improvised bitbanging simulation of serial comms through a PC
   parallel port. And besides that I usually program in a system which
   pauses from time to time for nonincremental garbage collection. But
   again, I think a system which can handle telephony could probably
   handle a superblitz game as well. And, while on a typical system today
   it'd likely be a noticeable programming challenge (one which is
   overcome by the telephony people routinely, but not without effort),
   the challenge should become smaller over time.

   (I don't know how much effort would be involved, but I think at least
   one would want to avoid the usual TCP, and instead either use some
   clever protocol with different design priorities, or use the naive
   approach of spraying identical UDP packets every ten milliseconds for
   100 milliseconds, then praying.:-)

   -- 
   William Harold Newman <william.newman@xxxxxxxxxxxxxxxxx>
   "Programming should be fun, programs should be beautiful." -- Paul Graham
   _______________________________________________
   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/