Re: [computer-go] Please have your bot resign, for your own good

[Raymond Wold]

On Fri, 2008-01-04 at 16:50 -0800, steve uurtamo wrote:
> TCP/IP communication can be viewed as round-trip.
> 
> UCP is one-way, TCP requires a response for each
> packet.
> 

For a high-level protocol, it's all the same. The fact that a TCP/IP
packet is acknowledged matters not at all because the stream data is
delivered to the application level at the same time as the acknowledge
packet is sent out, and the application can respond at once. Ping times
indicate how long it would take to send something to the client and get
a reply back, barring time needed to compute the reply.

As far as computer go servers matters, I do see that it harms anything
to give high-lag participants a chance to compete. Time controls is
never going to be fair anyway, unless you allocate time based on CPU
power, which I don't see how can work. It's just a way to limit games
from lasting too long.


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

Re: [computer-go] Please have your bot resign, for your own good

[steve uurtamo]

s/UCP/UDP/g;

- Original Message 
From: steve uurtamo <[EMAIL PROTECTED]>
To: computer-go 
Sent: Friday, January 4, 2008 7:50:34 PM
Subject: Re: [computer-go] Please have your bot resign, for your own good


TCP/IP communication can be viewed as round-trip.

UCP is one-way, TCP requires a response for each
packet.

s.


- Original Message 
From: Jason House <[EMAIL PROTECTED]>
To: computer-go 
Sent: Friday, January 4, 2008 4:50:31 PM
Subject: Re: [computer-go] Please have your bot resign, for your own good




On Jan 4, 2008 4:44 PM, Gian-Carlo Pascutto <[EMAIL PROTECTED]> wrote:

steve uurtamo wrote:
>> It was my understanding that the netlag to the Philippines was about
>> 380 ms; accounting for an additiaonal 15% packet loss and we end up
>> at about 440 ms.

>
> i think that it works out to roughly double that because of the protocol, 
> right?


Yes, the server sends out the move and starts your clock immediately.
You need 1 ping time to see the move and start calculating. After you

move, there's an additional ping time to get the move to CGOS.
Ping times are round trip.  I believe it should be 1/2 ping time to see the 
move and start calculating, and an additional 1/2 ping time to get the move to 
CGOS.










  Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.





  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[steve uurtamo]

TCP/IP communication can be viewed as round-trip.

UCP is one-way, TCP requires a response for each
packet.

s.


- Original Message 
From: Jason House <[EMAIL PROTECTED]>
To: computer-go 
Sent: Friday, January 4, 2008 4:50:31 PM
Subject: Re: [computer-go] Please have your bot resign, for your own good




On Jan 4, 2008 4:44 PM, Gian-Carlo Pascutto <[EMAIL PROTECTED]> wrote:

steve uurtamo wrote:
>> It was my understanding that the netlag to the Philippines was about
>> 380 ms; accounting for an additiaonal 15% packet loss and we end up
>> at about 440 ms.

>
> i think that it works out to roughly double that because of the protocol, 
> right?


Yes, the server sends out the move and starts your clock immediately.
You need 1 ping time to see the move and start calculating. After you

move, there's an additional ping time to get the move to CGOS.
Ping times are round trip.  I believe it should be 1/2 ping time to see the 
move and start calculating, and an additional 1/2 ping time to get the move to 
CGOS.










  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Jason House]

On Jan 4, 2008 4:44 PM, Gian-Carlo Pascutto <[EMAIL PROTECTED]> wrote:

> steve uurtamo wrote:
> >> It was my understanding that the netlag to the Philippines was about
> >> 380 ms; accounting for an additiaonal 15% packet loss and we end up
> >> at about 440 ms.
> >
> > i think that it works out to roughly double that because of the
> protocol, right?
>
> Yes, the server sends out the move and starts your clock immediately.
> You need 1 ping time to see the move and start calculating. After you
> move, there's an additional ping time to get the move to CGOS.


Ping times are round trip.  I believe it should be 1/2 ping time to see the
move and start calculating, and an additional 1/2 ping time to get the move
to CGOS.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Gian-Carlo Pascutto]

steve uurtamo wrote:

It was my understanding that the netlag to the Philippines was about
380 ms; accounting for an additiaonal 15% packet loss and we end up
at about 440 ms.


i think that it works out to roughly double that because of the protocol, right?


Yes, the server sends out the move and starts your clock immediately.
You need 1 ping time to see the move and start calculating. After you
move, there's an additional ping time to get the move to CGOS.

--
GCP
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[steve uurtamo]

> It was my understanding that the netlag to the Philippines was about
> 380 ms; accounting for an additiaonal 15% packet loss and we end up
> at about 440 ms.

i think that it works out to roughly double that because of the protocol, right?

s.



  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Christoph Birk]

On Fri, 4 Jan 2008, Don Dailey wrote:

It was my understanding the bot was losing 2 seconds per move.   1/2
second would probably not fix this.


It was my understanding that the netlag to the Philippines was about
380 ms; accounting for an additiaonal 15% packet loss and we end up
at about 440 ms.

http://computer-go.org/pipermail/computer-go/2008-January/013125.html

Christoph

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

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

It was my understanding the bot was losing 2 seconds per move.   1/2
second would probably not fix this.

- Don


Christoph Birk wrote:
> On Fri, 4 Jan 2008, Don Dailey wrote:
>> I think Fischer time is the solution to network lag.   I can't give back
>> the lag time, but I can make it so that you should not lose games as a
>> result of it (unless it gets ridiculous.)
>
> I don't object to Fisher Time but just increasing the move-credit
> to 0.5 or even 1 second would do the trick.
>
> Chrsitoph
>
>
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

[EMAIL PROTECTED] wrote:
> After 2000 playouts, AntIgo checks the estimated score. If it's way
> ahead, it stops thinking and just plays the best move it has so far.
> This way it plays very quickly when the game is won and the opponent
> does not resign. (I don't apply this rule in the beginning to avoid
> confusion in handicap games.)
>  
> AntIgo gambles that thinking a long time on early moves can buy it a
> won position. Sometimes the gamble pays off, sometimes not. Another
> benefit is that games against random/near-random bots are mercifully
> swift.
It's clearly a good gamble to front load the time fairly
significantly. It's difficult to determine exactly how much
though. Many games are won or lost after just a few moves.   
However games against the strong bots tend to stay relatively even for
many moves.   

- Don


> - Dave Hillis
>
> 
> More new features than ever. Check out the new AIM(R) Mail
> !
> 
>
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Christoph Birk]

On Fri, 4 Jan 2008, Don Dailey wrote:

I think Fischer time is the solution to network lag.   I can't give back
the lag time, but I can make it so that you should not lose games as a
result of it (unless it gets ridiculous.)


I don't object to Fisher Time but just increasing the move-credit
to 0.5 or even 1 second would do the trick.

Chrsitoph


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

Re: [computer-go] Please have your bot resign, for your own good

[dhillismail]

After 2000 playouts, AntIgo checks the estimated score. If it's way ahead, it 
stops thinking and just plays the best move it has so far. This way it plays 
very quickly when the game is won and the opponent does not resign. (I don't 
apply this rule in the beginning to avoid confusion in handicap games.)
?
AntIgo gambles that thinking a long time on early moves can?buy it a won 
position. Sometimes the gamble pays off, sometimes not. Another benefit is that 
games against random/near-random bots are mercifully swift.

- Dave Hillis



More new features than ever.  Check out the new AIM(R) Mail ! - 
http://webmail.aim.com
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

I think Fischer time is the solution to network lag.   I can't give back
the lag time, but I can make it so that you should not lose games as a
result of it (unless it gets ridiculous.)

- Don


Jacques Basaldúa wrote:
> The problem is avoiding that an inferior program wins a lost position
> on time extending the number of moves. If you could choose, what side
> would you prefer to be? As a human, there is no doubt. But as a program
> it is even better: the strongest program. Because computers can play
> faster
> than humans.
>
> It is so much easier to make a strong program manage its time better
> than to make a weak and fast program stronger. Therefore, I propose
> a silly idea:
>
> Introduce a bot (I suggest the name "mosquito") *intentionally* that
> tries to exploit time weakness. Just an ultra blitz player that plays
> some
> good looking move at 1 ply without search and never resigns. If your
> program loses games against mosquito you have to improve your time
> management.
>
> If there is a mosquito (annoying but otherwise harmless insect) always
> present in the system, serious programs will have extra motivation
> to care about time management.
>
> Of course, its only a half serious proposal. And the problem with the
> Philippines won't be solved, perhaps it just a mater of increasing the
> 1/4 sec extra time to 1/3 or something like that. Of course that is not
> fair, because it is an advantage for those with better connections, but
> that cannot be avoided. Working with 16 cores is a much bigger
> advantage and is not avoided either.
>
> Jacques.
>
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Jacques Basaldúa]

The problem is avoiding that an inferior program wins a lost position
on time extending the number of moves. If you could choose, what side
would you prefer to be? As a human, there is no doubt. But as a program
it is even better: the strongest program. Because computers can play faster
than humans.

It is so much easier to make a strong program manage its time better
than to make a weak and fast program stronger. Therefore, I propose
a silly idea:

Introduce a bot (I suggest the name "mosquito") *intentionally* that
tries to exploit time weakness. Just an ultra blitz player that plays some
good looking move at 1 ply without search and never resigns. If your
program loses games against mosquito you have to improve your time
management.

If there is a mosquito (annoying but otherwise harmless insect) always
present in the system, serious programs will have extra motivation
to care about time management.

Of course, its only a half serious proposal. And the problem with the
Philippines won't be solved, perhaps it just a mater of increasing the
1/4 sec extra time to 1/3 or something like that. Of course that is not
fair, because it is an advantage for those with better connections, but
that cannot be avoided. Working with 16 cores is a much bigger
advantage and is not avoided either.

Jacques.

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

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

Robert Jasiek wrote:
> Jason House wrote:
> > I missed [...] the part about
>> solving how to end the game in an elegant way.
>
> "elegant" is an aspect of art, and I have not studied it profoundly in
> relation to rules yet because I concentrate on things that can be
> derived from definitions and evaluated by objective derivation from them.
>
> Some consider it elegant to play on until the board is filled with
> 2-liberty strings - others consider it elegant to stop playing at the
> Japanese opinion of what worthless moves are (but symmetrical yose is
> not considered worthless by them).
>
> So you see, "elegance" depends on which definition one chooses.
>
In other words, elegance is subjective - it cannot be defined in some
mathematically rigid way.It's pretty much like beauty,  it's in the
eye of the beholder.


- Don

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

Re: [computer-go] Please have your bot resign, for your own good

[Robert Jasiek]

Jason House wrote:
> I missed [...] the part about

solving how to end the game in an elegant way.


"elegant" is an aspect of art, and I have not studied it profoundly in 
relation to rules yet because I concentrate on things that can be 
derived from definitions and evaluated by objective derivation from them.


Some consider it elegant to play on until the board is filled with 
2-liberty strings - others consider it elegant to stop playing at the 
Japanese opinion of what worthless moves are (but symmetrical yose is 
not considered worthless by them).


So you see, "elegance" depends on which definition one chooses.

--
robert jasiek
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[William Harold Newman]

On Wed, Jan 02, 2008 at 07:25:00PM -0800, David Fotland wrote:
> Japanese rules.  I know people on this list don't like them, but the game
> plays out almost the same as with Chinese rules, but since there is a one
> point penalty for playing inside your own territory, the game ends much
> earlier.

I really don't like Japanese rules for automated servers, and don't
even much like them for serious computer tournaments, because they
seem to have corner cases which are tricky even for humans, while TT
playout could probably be defined on a napkin. 
 
The interaction of perverse playouts with netlag does sound really
irritating, though, enough that I'd tentatively support complicating
the playout rules to support it --- if not necessarily for occasional
high-visibility computer tournaments between highly competent programs
played on LANs with negligible lag, at least for thousands-of-games
open-to-all Internet ladder servers.

For such open-to-all servers, I think it'd be reasonable to use
something like Robert Jasiek's proposal of a hard cutoff at some large
number of moves --- perhaps two or three times the number of squares
on the board. That'd be a slightly inelegant gratuitous addition to
the ruleset, but one with an invisibly small effect on well-played
games and the advantage of eliminating the visible practical problem
of unbounded netlag in poorly-played games. (At least I assume it'd be
invisible: as far as I know there is no evidence that this would have
a significant effect on even one in a million reasonably-well-played
games. If some future breakthrough in strategy causes ultra-long games
to become more common, I'd want the now-irritatingly-visible cutoff to
be removed.)

Another possibility might be putting a cutoff on some other quantity
that an automated server can easily measure which is small in a
well-played game, but which is chosen for rapid growth in the kinds of
perverse playouts which are causing problems in practice. For example,
perhaps something like MY_STONES plus the product of MY_NET_PASSES and
HIS_SQUARED_POSTPASS_SACRIFICES.

MY_STONES is the number of my stones remaining on the board.

MY_NET_PASSES is the difference between the number of times I have 
passed and the number of times my opponent has passed, or zero if
that difference would be negative.

HIS_SQUARED_POSTPASS_SACRIFICES is the sum of squares of sizes of
groups which my opponent created after my pass(es) and which then got
captured.

I'll be mildly surprised (because of worries about perverse seki
situations and such) if this particular quantity is robust enough
to serve as a really good cutoff (as in "if
MY_STONES + MY_NET_PASSES * HIS_SQUARED_POSTPASS_SACRIFICES
exceeds the number of squares on the board, the game is won").
However, it won't surprise me if something in a similar spirit turns
out to be usefully robust.

-- 
William Harold Newman <[EMAIL PROTECTED]>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C
Of course one could write a computer program to converse like Disraeli
or Churchill, by simply storing every possible quip and counterquip.
But that's the sort of overfitting up with which we must not put!
  -- http://www.scottaaronson.com/democritus/lec10.5.html
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

John Tromp wrote:
> On Jan 3, 2008 10:46 AM, Don Dailey <[EMAIL PROTECTED]> wrote:
>   
>> Yes, the KGS rules gives only 1 chance to agree.   At one point KGS
>> allowed this to happen repeatedly, but it cause some bots to infinite
>> loop on the server when they disagreed. So I think it's better than
>> nothing, but imperfect.
>> 
>
> Infinite loops are impossible if the server ends the game with
> board scoring after 4 consecutive passes
> (i.e. after 2 passes, and disagreement, both players pass again).
> It is up to the player who is behind in board score to make a move
> in the continuation, in order to avoid losing.
>   
Yes, I think this protocol works quite well.If I ever implement it
on CGOS I would probably do it this way - since it is almost compatible
with KGS.


- Don



> regards,
> -John
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>   
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

I have to correct this slightly.  


Don Dailey wrote:
> Just for fun I thought of a simple protocol for ending the game earlier
> that I think would work:
>
> Each program, when it sends it's move to the server can optionally send
> 2 lists of dead stones to the server.   The first list represents the
> status of the board BEFORE the move is played and the second list
> represents the status of the stones AFTER the move is played.  
>
> If the "after" list of the one player matches the "before" list of the
> following player,   the game is ended with the last 2 moves replaced by
> pass moves.  
>   
Actually,  the last player is assumed to pass and an additional pass is
inserted for the first player.

- Don


> The lists are optional, so a program doesn't have to use this protocol
> unless it wants to.   The lists are also completely anonymous to the
> opponent to avoid any gamesmanship. It doesn't change anything on
> the  server from the viewpoint of a program that doesn't want to use it.
>
> A program will not send this list unless it intends to pass and
> considers the game played out.The agreed upon dead stones would be
> removed and the game scored.  
>
> - Don
>
>  
>
>
>
> Don Dailey wrote:
>   
>> David Fotland wrote:
>>   
>> 
>>> Japanese rules.  I know people on this list don't like them, but the game
>>> plays out almost the same as with Chinese rules, but since there is a one
>>> point penalty for playing inside your own territory, the game ends much
>>> earlier.
>>>   
>>> 
>>>   
>> The real issue on a server that involves computers is having a simple
>> bullet-proof protocol for ending the game and getting the correct
>> score.CGOS method is very clean, simple and correct.  Computers
>> don't have ego's and will not fight if they get cheated.On KGS when
>> my bot played I got situations where my program won, but the opponent
>> just marked all my programs stone as dead.   KGS didn't have a protocol
>> for contesting this.   I didn't really care since the games were not
>> rated but it was ugly nonetheless.
>>
>> I think KGS has something now involving sending a dead stone list to the
>> server, but it's not perfect.   Without a great deal of expertise and
>> getting the protocol just right,  games can get scored wrong. In
>> fact, even with the best of intentions and well behaved strong programs
>> I think it's possible to get some games scored incorrectly with Japanese
>> rules and computer play automated.
>>
>> But for ending the game early, you have to get into this.   I don't
>> think it's a Japanese vs Chinese issue, but more about agreeing on dead
>> stones.Although this is usually simple,  there can be complicated
>> cases that even a good program cannot score correctly.   
>>
>> If I were to take it to the next step (which I'm not inclined to do) I
>> would try to find a way to allow early passes.I think this is
>> actually counter-productive though.It would make it more difficult
>> to get on CGOS by raising the bar and I don't want that.
>>
>> - Don
>>
>>
>>
>>   
>> 
>>> David
>>>
>>>   
>>> 
>>>   
 This raises an interesting (to me) theoretical question: is there a
 ruleset that allows games to end in a more reasonable time without
 changing general play?  
 
   
 
>>> ___
>>> computer-go mailing list
>>> computer-go@computer-go.org
>>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>>
>>>   
>>> 
>>>   
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>>   
>> 
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>   
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[John Tromp]

On Jan 3, 2008 10:46 AM, Don Dailey <[EMAIL PROTECTED]> wrote:
> Yes, the KGS rules gives only 1 chance to agree.   At one point KGS
> allowed this to happen repeatedly, but it cause some bots to infinite
> loop on the server when they disagreed. So I think it's better than
> nothing, but imperfect.

Infinite loops are impossible if the server ends the game with
board scoring after 4 consecutive passes
(i.e. after 2 passes, and disagreement, both players pass again).
It is up to the player who is behind in board score to make a move
in the continuation, in order to avoid losing.

regards,
-John
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

Jason House wrote:
>
>
> On Jan 3, 2008 10:21 AM, Don Dailey <[EMAIL PROTECTED]
> > wrote:
>
>
>
> Robert Jasiek wrote:
> > Don Dailey wrote:
> > > you can never solve the problem of a
> >> malicious opponent who wants to prolong the game needlessly.
> >
> > I solved that many years ago: Constant game end rule.
> > http://home.snafu.de/jasiek/endrules.html
> >
> > The question is rather whether one wants such a rule. (I do not like
> > it because it is artificial.)
> >
> Interesting web site - I enjoyed reading it and it seems well
> thought out.
>
>
> It looked to be lots of classification and description of pre-existing
> rules. I missed (or possibly tuned out prior to reading) the part
> about solving how to end the game in an elegant way.
>
> Which section should I read?
He already specified the section to read.  

>
> BTW - The KGS game end protocol requires both bots to pass to initiate
> scoring.  Both sides then give a list of dead stones.  If they agree,
> the game is over.  If there's any disagreement, the bots must finish
> the game like on CGOS (all remaining stones are alive).

Yes, the KGS rules gives only 1 chance to agree.   At one point KGS
allowed this to happen repeatedly, but it cause some bots to infinite
loop on the server when they disagreed. So I think it's better than
nothing, but imperfect. 

- Don


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

Re: [computer-go] Please have your bot resign, for your own good

[Jason House]

On Jan 3, 2008 10:21 AM, Don Dailey <[EMAIL PROTECTED]> wrote:

>
>
> Robert Jasiek wrote:
> > Don Dailey wrote:
> > > you can never solve the problem of a
> >> malicious opponent who wants to prolong the game needlessly.
> >
> > I solved that many years ago: Constant game end rule.
> > http://home.snafu.de/jasiek/endrules.html
> >
> > The question is rather whether one wants such a rule. (I do not like
> > it because it is artificial.)
> >
> Interesting web site - I enjoyed reading it and it seems well thought out.
>

It looked to be lots of classification and description of pre-existing
rules. I missed (or possibly tuned out prior to reading) the part about
solving how to end the game in an elegant way.

Which section should I read?

BTW - The KGS game end protocol requires both bots to pass to initiate
scoring.  Both sides then give a list of dead stones.  If they agree, the
game is over.  If there's any disagreement, the bots must finish the game
like on CGOS (all remaining stones are alive).
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

Robert Jasiek wrote:
> Don Dailey wrote:
> > you can never solve the problem of a
>> malicious opponent who wants to prolong the game needlessly.
>
> I solved that many years ago: Constant game end rule.
> http://home.snafu.de/jasiek/endrules.html
>
> The question is rather whether one wants such a rule. (I do not like
> it because it is artificial.)
>
Interesting web site - I enjoyed reading it and it seems well thought out.

- Don




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

Re: [computer-go] Please have your bot resign, for your own good

[Robert Jasiek]

Don Dailey wrote:
> you can never solve the problem of a

malicious opponent who wants to prolong the game needlessly.


I solved that many years ago: Constant game end rule.
http://home.snafu.de/jasiek/endrules.html

The question is rather whether one wants such a rule. (I do not like it 
because it is artificial.)


--
robert jasiek
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

Robert Jasiek wrote:
> Don Dailey wrote:
>>> This raises an interesting (to me) theoretical question: is there a
>>> ruleset that allows games to end in a more reasonable time without
>>> changing general play?  
>> There is no such rule-set that I know of.
>
> If it is specified more clearly what "end in a more reasonable time
> without changing general play" shall mean, I might give an answer.

No matter how you look at it, you can never solve the problem of a
malicious opponent who wants to prolong the game needlessly. You can
only try to punish him for doing so with something like Japanese
scoring.But if a player is already losing the game there is no
incentive NOT to fill in every point and play to the bitter end.

- Don

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

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

Just for fun I thought of a simple protocol for ending the game earlier
that I think would work:

Each program, when it sends it's move to the server can optionally send
2 lists of dead stones to the server.   The first list represents the
status of the board BEFORE the move is played and the second list
represents the status of the stones AFTER the move is played.  

If the "after" list of the one player matches the "before" list of the
following player,   the game is ended with the last 2 moves replaced by
pass moves.  

The lists are optional, so a program doesn't have to use this protocol
unless it wants to.   The lists are also completely anonymous to the
opponent to avoid any gamesmanship. It doesn't change anything on
the  server from the viewpoint of a program that doesn't want to use it.

A program will not send this list unless it intends to pass and
considers the game played out.The agreed upon dead stones would be
removed and the game scored.  

- Don

 



Don Dailey wrote:
> David Fotland wrote:
>   
>> Japanese rules.  I know people on this list don't like them, but the game
>> plays out almost the same as with Chinese rules, but since there is a one
>> point penalty for playing inside your own territory, the game ends much
>> earlier.
>>   
>> 
> The real issue on a server that involves computers is having a simple
> bullet-proof protocol for ending the game and getting the correct
> score.CGOS method is very clean, simple and correct.  Computers
> don't have ego's and will not fight if they get cheated.On KGS when
> my bot played I got situations where my program won, but the opponent
> just marked all my programs stone as dead.   KGS didn't have a protocol
> for contesting this.   I didn't really care since the games were not
> rated but it was ugly nonetheless.
>
> I think KGS has something now involving sending a dead stone list to the
> server, but it's not perfect.   Without a great deal of expertise and
> getting the protocol just right,  games can get scored wrong. In
> fact, even with the best of intentions and well behaved strong programs
> I think it's possible to get some games scored incorrectly with Japanese
> rules and computer play automated.
>
> But for ending the game early, you have to get into this.   I don't
> think it's a Japanese vs Chinese issue, but more about agreeing on dead
> stones.Although this is usually simple,  there can be complicated
> cases that even a good program cannot score correctly.   
>
> If I were to take it to the next step (which I'm not inclined to do) I
> would try to find a way to allow early passes.I think this is
> actually counter-productive though.It would make it more difficult
> to get on CGOS by raising the bar and I don't want that.
>
> - Don
>
>
>
>   
>> David
>>
>>   
>> 
>>> This raises an interesting (to me) theoretical question: is there a
>>> ruleset that allows games to end in a more reasonable time without
>>> changing general play?  
>>> 
>>>   
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>>   
>> 
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>   
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

David Fotland wrote:
> Japanese rules.  I know people on this list don't like them, but the game
> plays out almost the same as with Chinese rules, but since there is a one
> point penalty for playing inside your own territory, the game ends much
> earlier.
>   
The real issue on a server that involves computers is having a simple
bullet-proof protocol for ending the game and getting the correct
score.CGOS method is very clean, simple and correct.  Computers
don't have ego's and will not fight if they get cheated.On KGS when
my bot played I got situations where my program won, but the opponent
just marked all my programs stone as dead.   KGS didn't have a protocol
for contesting this.   I didn't really care since the games were not
rated but it was ugly nonetheless.

I think KGS has something now involving sending a dead stone list to the
server, but it's not perfect.   Without a great deal of expertise and
getting the protocol just right,  games can get scored wrong. In
fact, even with the best of intentions and well behaved strong programs
I think it's possible to get some games scored incorrectly with Japanese
rules and computer play automated.

But for ending the game early, you have to get into this.   I don't
think it's a Japanese vs Chinese issue, but more about agreeing on dead
stones.Although this is usually simple,  there can be complicated
cases that even a good program cannot score correctly.   

If I were to take it to the next step (which I'm not inclined to do) I
would try to find a way to allow early passes.I think this is
actually counter-productive though.It would make it more difficult
to get on CGOS by raising the bar and I don't want that.

- Don



> David
>
>   
>> This raises an interesting (to me) theoretical question: is there a
>> ruleset that allows games to end in a more reasonable time without
>> changing general play?  
>> 
>
>
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>   
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Robert Jasiek]

Don Dailey wrote:

This raises an interesting (to me) theoretical question: is there a
ruleset that allows games to end in a more reasonable time without
changing general play?  

There is no such rule-set that I know of.


If it is specified more clearly what "end in a more reasonable time 
without changing general play" shall mean, I might give an answer.


--
robert jasiek
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

Thomas Nelson wrote:
>
>
> On Wed, 2 Jan 2008, Don Dailey wrote:
>
>> If we don't like the rules, we can talk about changing them in order to
>> get behavior that fits our sensibilities better.But we have been
>> over this ground many times before.   It seems like the only reasonable
>> way to properly score games is to play them out - and hence the use of
>> tromp taylor rules.   In order to help the situation I made suicide
>> illegal on CGOS.
>>
>> - Don
>
> This raises an interesting (to me) theoretical question: is there a
> ruleset that allows games to end in a more reasonable time without
> changing general play?  
There is no such rule-set that I know of.   Some people claim Japanese
scoring ends the games earlier but that still doesn't prevent players
from playing out the game needlessly - it only penalizes them for doing
so. 

CGOS uses Chinese scoring with play-outs so that we can get fully
automated scoring with no chance of errors.

- Don
  


> I've tried teaching many beginners to play go, usually on a small
> board.  I prefer a "hands-off" style, just explaining the rules and
> letting them play until they want to pass.  But this always leads to
> games lasting two or three times as long as they need to, since the
> person playing their first game has no idea when to stop and keeps
> playing dead stones.  If try to stop them and say "that stone will day
> as soon as you place it", they have to just take my word for it, or we
> keep playing out.  Really, when two players of reasonable skill level
> play, they continue until the winner, or at least the score, is clear,
> then stop.  This is somewhat like the "end the game when it becomes
> statically sloveable" idea.  I wonder if it would be possible to have
> some referee type bot that could stop the game when it was certain of
> the outcome.  I could even imagine an alternate go ruleset where there
> was no passing at all, but the game ended when the fate of each point
> on the board was certain.  Of course, implementing those rules would
> require a fairly strong go playing agent, and it's quite possible
> lower-skilled agents would disagree with its assessment!
>
> -Tom
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[David Doshay]

True, there is no other game quite like Go in the western world, so  
it takes a few games to figure these things out. I help this  
"problem" in the learning curve along by starting on 5x5 boards and  
then moving up to 7x7 boards. It lets beginners see the end quickly  
and lessens the time between when a move is made and when the outcome  
becomes clear. This speeds learning in the long run.


Cheers,
David



On 2, Jan 2008, at 7:08 PM, Thomas Nelson wrote:

I've tried teaching many beginners to play go, usually on a small  
board.  I prefer a "hands-off" style, just explaining the rules and  
letting them play until they want to pass.  But this always leads  
to games lasting two or three times as long as they need to, since  
the person playing their first game has no idea when to stop and  
keeps playing dead stones.


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

RE: [computer-go] Please have your bot resign, for your own good

[David Fotland]

Japanese rules.  I know people on this list don't like them, but the game
plays out almost the same as with Chinese rules, but since there is a one
point penalty for playing inside your own territory, the game ends much
earlier.

David

> 
> This raises an interesting (to me) theoretical question: is there a
> ruleset that allows games to end in a more reasonable time without
> changing general play?  


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

Re: [computer-go] Please have your bot resign, for your own good

[Thomas Nelson]

On Wed, 2 Jan 2008, Don Dailey wrote:


If we don't like the rules, we can talk about changing them in order to
get behavior that fits our sensibilities better.But we have been
over this ground many times before.   It seems like the only reasonable
way to properly score games is to play them out - and hence the use of
tromp taylor rules.   In order to help the situation I made suicide
illegal on CGOS.

- Don


This raises an interesting (to me) theoretical question: is there a 
ruleset that allows games to end in a more reasonable time without 
changing general play?  I've tried teaching many beginners to play go, 
usually on a small board.  I prefer a "hands-off" style, just explaining 
the rules and letting them play until they want to pass.  But this always 
leads to games lasting two or three times as long as they need to, since 
the person playing their first game has no idea when to stop and keeps 
playing dead stones.  If try to stop them and say "that stone will day as 
soon as you place it", they have to just take my word for it, or we keep 
playing out.  Really, when two players of reasonable skill level play, 
they continue until the winner, or at least the score, is clear, then 
stop.  This is somewhat like the "end the game when it becomes statically 
sloveable" idea.  I wonder if it would be possible to have some referee 
type bot that could stop the game when it was certain of the outcome.  I 
could even imagine an alternate go ruleset where there was no passing at 
all, but the game ended when the fate of each point on the board was 
certain.  Of course, implementing those rules would require a fairly 
strong go playing agent, and it's quite possible lower-skilled agents 
would disagree with its assessment!


-Tom
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

They are not on a fixed schedule.   I currently just start a round
whenever the previous round is finished.

I will probably add another time-control too.  There will one long time
control,  and short time controls games in between.   When a long game
is complete, you will start a short time control game.But a long
time control game will not begin until all logged in players are
finished with the shorter games.   In this way all players will play in
the long time control games (unless they just want short games) and all
players will stay busier.   There will be an option to play in just one
time-control or both. 

- Don



Jeff Nowakowski wrote:
> On Wed, 2008-01-02 at 15:29 -0500, Don Dailey wrote:
>   
>> I am considering to implement Fischer time on CGOS
>> 
>
> How are you going to deal with keeping the games on a fixed schedule?
>
> -Jeff
>
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>   
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[dhillismail]

Maybe some day computer go will reach the same level of "maturity" as computer 
chess and we will need safeguards against all sorts of churlishness. But so 
far, CGOS is very civilized.

I favor encouraging people to make their bots resign, but not penalizing those 
who don't. The MC programs are dominant enough already. 

It was utterly trivial to make my MC program resign from a lost position: maybe 
3 lines of code. On the other hand, I have a neural net bot which has no 
concept of gobal score and just looks for good moves. There's no way I'm going 
to bother modifying it to know when to resign. I'd have to graft a whole new 
engine on top of it. It would be like adding an air conditioner to a bicycle.

The neural net isn't as strong as a good MC program but it's stronger than a 
lot of bad ones. And, with the right time limits, it would probably beat all of 
them. :)

The TT rules make it easy for different algorithms to compete. I'd much rather 
see different time rules (like Fischer) than backing away from TT scoring.

- Dave Hillis






More new features than ever.  Check out the new AIM(R) Mail ! - 
http://webmail.aim.com
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Jason House]

On Jan 2, 2008 3:29 PM, Don Dailey <[EMAIL PROTECTED]> wrote:

> I am considering to implement Fischer time on CGOS, but I would like it
> to be  painless. I don't believe GTP has a provision to handle it -
> but I will check to see what it does have.   (I have no intentions of
> doing the byo-yomi stuff.)


The command kgs-time_settings is more flexible for adding new time
management methods.  If you do go down the road of updating the time
control, I'd request that you consider reporting fractional seconds similar
to what the CGOS client receives from the server.  This would allow me to
add better adaptive time control logic.  Instead of looking at the average
time lost between moves and assuming a distribution, it could examine
individual samples and estimate the distribution.

I agree that Fischer time is simpler to handle.  For those that don't think
byo yomi time is that different, below is my implementation for handling byo
yomi.

I split time management into 4 phases:
phase 1 - plenty of time left - use x% of time left
phase 2 - low on main time - use 2x byo yomi period
phase 3 - near end of main time
  Compute n = # of moves that can be done in
(main time) + (one byo yomi period),
assuming 2x byo yomi period per move.
  Use [(main time) + (one byo yomi period)]/ceiling(n)
phase 4 - in overtime - use entire byo yomi period, less buffer for lag

I'm typing up the behavior from memory, but that should be very close to how
it behaves.  This gives a nicely behaved monotonically decreasing time
usage.  For those that are not crazy enough to implement that, the code for
that is available under GPLv3.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Jeff Nowakowski]

On Wed, 2008-01-02 at 15:29 -0500, Don Dailey wrote:
> I am considering to implement Fischer time on CGOS

How are you going to deal with keeping the games on a fixed schedule?

-Jeff

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

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

I am considering to implement Fischer time on CGOS, but I would like it
to be  painless. I don't believe GTP has a provision to handle it -
but I will check to see what it does have.   (I have no intentions of
doing the byo-yomi stuff.)

However, even without a change to your program Fischer time  would still
work.   You just wouldn't utilize time quite as effectively.

The client could have a mode that "helps" the engine allocate time more
wisely by reporting some of the future surplus time that will be
available in advance.   Of course there would probably have to be an
extended GTP command that programs could optionally use.

Fischer time is a wonderful time control for computer players.   It
takes most of the burden and uncertainty involving game length out of
the equation.  

- Don
  



steve uurtamo wrote:
> i like don's idea about using fischer time.  byo-yomi seems to be
> the obvious solution to the problem (just make it a small byo-yomi time,
> something like 5 seconds), but fischer time has some pretty magical
> features that computers can easily take advantage of.  time management
> should be quite a bit easier under fisher time, for instance, than with
> something as complicated as byo-yomi, or something as delta-function as
> absolute time.  even canadian time management is more complicated.
>
> just a few nits...
>
>   
>> imagine 1 second per move, plus 2 seconds of net lag, in which case the
>> programs have 1 second per move to think, plus 2+1+2 seconds between
>> moves to ponder.
>> 
>
> although it doesn't matter much, i doubt that anyone connecting their bot
> to CGOS has 2 seconds of net lag per move, every move.  so it's kind've
> a straw-man argument.  500-750ms is a reasonable upper-bound on the
> average delay between two arbitrary machines when one is well-connected and
> the other isn't in a third-world country.
>
>   
>> Also, if programs prolong the game as much as possible, it means that
>> the next round of ALL programs will be delayed, and the more programs
>> you have that deliberately refuse to resign, the greater the probability 
>> that you
>> will get two that, because of a failure on the part of the leader to
>> correctly bring the game to a close, play a match that goes on
>> basically forever. In that case, only a double-forfeit is sufficient
>> -- switching to true absolute time limits would not be good enough,
>> 
>
> by "basically forever" are you imagining a situation where legal moves are
> played one after the other that both:
>
> i) don't violate superko
> ii) don't create a massive disadvantage for the person playing the move.
>
> i guess i'm not imaginative enough today, but i am having trouble envisioning
> a board where you would have both of these conditions hold *for both players*
> for "basically forever" (where basically forever can be defined to be some 
> huge
> number of moves).
>
> also, i don't think that it should delay anything for anyone else on CGOS, 
> would it?
> is this even a practical/pragmatic concern in tournaments?  have there been 
> KGS
> tournaments (or otherwise) that were held up "basically forever" because of 
> extremely
> unfortunate play between two opponents?
>
>   
>> because two players in a "Who can play stupid moves fastest?" battle
>> could swamp the network and cause lag for programs playing real games.
>> 
>
> this sounds wrong to me.  if the server can dequeue the packets at roughly
> the same rate that they're coming in (and keep in mind that player B won't 
> send
> a new move packet until the server has already dealt with player A's move 
> packet), the
> packet sizes and bitrates involved should never swamp any reasonably 
> well-connected
> machine on a modern network.  you would need very many people doing this
> simultaneously for it to be a real problem.  either that, or a very, very 
> stupid protocol.
>
> s.
>
>
>
>   
> 
> Looking for last minute shopping deals?  
> Find them fast with Yahoo! Search.  
> http://tools.search.yahoo.com/newsearch/category.php?category=shopping
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>   
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

Hi Eric,

I think there are rules and there is etiquette.   Rules you can control,
but etiquette you cannot.   You can never stop bad behavior and have the
additional problem that you must "judge" it. You have to decide in
which case a player exercised bad manners and so on. It's a tough thing.

I totally disagree with you on whether playing out a game to the bitter
end is defensible or not.   If it's in the rules,  of course it's
perfectly defensible.Nobody (or no program) should be criticized for
following the rules or even trying to use them to it's advantage.   
That's the whole idea of rules - to define what behavior is acceptable
and what is not.

For example - if it's known that my program allocates too much time to
the early moves,  it should not be YOUR responsibility to resign or pass
just so that I don't have to mange my time. 

Is it childish to play out a game hoping for a time-control win in a
dead lost position?   I don't think so.   You may very well be losing
the game because the opponent took too much time building up a won
position.   This is not a corner case, it is very common.

I've seen this happy to Lazarus when I was testing time-control and
trying to tune it.Lazarus would get a won position and the opponent
would resign - and surely  would have won if it had kept playing due to
the fact that Lazarus didn't have much time left.

Now should I have felt good or bad about that win?I felt bad even
though the game was won.   To see why,  imagine that I kept the
aggressive time-control in my program.Then I could have waved my
hands and complained every time I lost a "won" game.I could have
mumbled something about the opponent not resigning or passing when he
"should have" and so on. In other words, I can pass the buck,  or I
can just make sure Lazarus doesn't lose games this way - or I can take
my chances. I can use aggressive time-control logic in my program
and hope that it causes me more wins than losses.But I cannot have
it both ways.In other words, I have to play by the rules and the
constraints they impose.   It wouldn't be any fun otherwise.

If we don't like the rules, we can talk about changing them in order to
get behavior that fits our sensibilities better.But we have been
over this ground many times before.   It seems like the only reasonable
way to properly score games is to play them out - and hence the use of
tromp taylor rules.   In order to help the situation I made suicide
illegal on CGOS.

- Don




Eric Boesch wrote:
> In chess, playing the game out to the bitter end can be defensible,
> but in go, it isn't. The meaning of the "end of the game" in go is
> fluid, but it's not "when it's no longer possible to play a move". In
> absolute time limit games, when significant per-move lag exists (which
> is true in all human matches and some computer ones), it is impossible
> to schedule correctly to deal with the possibility that the opponent
> will continue playing for as long as possible after the game is
> already over. Either you allocate too little time for the real game,
> putting yourself at a disadvantage if you and your opponent play
> reasonably, or you leave yourself without enough time to handle
> unreasonable play. All go players know how to keep playing after the
> game ends, but it's as childish and outside the spirit of the rules as
> starting a no time limit game, realizing you have fallen behind, and
> never returning to the board. In the eyes of most players, a time win
> in a lost position well after the game has ended isn't even a
> win-with-an-asterisk -- it's a dead loss, even moreso if the player
> with the winning position played as quickly as lag would permit. This
> is why byo yomi can actually shorten games: compared to absolute time,
> it removes much of the incentive for children to keep playing after
> the game is over.
>
> All methods of compensating for net lag require some level of trust.
> Even if a fraud-proof way to detect net lag existed, it would
> interfere with time controls and scheduling. If it takes a second
> before program B knows what move program A played, then that's a
> second during which program A has better information about the game
> than program B has. You can say that it hopefully averages out in the
> wash, but the possibility that a program might gain an advantage from
> its poor network connection is still there. Any compensation for net
> lag at all means that a program that ponders gains a greater advantage
> than the official time controls would suggest: imagine 1 second per
> move, plus 2 seconds of net lag, in which case the programs have 1
> second per move to think, plus 2+1+2 seconds between moves to ponder.
> So I think Peter was right to direct his request to other programmers,
> instead of asking Don to compensate for net lag.
>
> I was going to suggest copying KGS's "no time cost for a pass within a
> reasonable number of seconds" rule, but I see Erik 

Re: [computer-go] Please have your bot resign, for your own good

[Christoph Birk]

On Wed, 2 Jan 2008, Don Dailey wrote:

Better would be some kind of victory declaration.The program claims
victory - which means that it agrees that every move from now on (for
itself) is a pass move.


I disagree. Increasing the time-allowance for a PASS move is simpler
and more elegant IMHO.

Christoph

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

Re: [computer-go] Please have your bot resign, for your own good

[Christoph Birk]

On Wed, 2 Jan 2008, Eric Boesch wrote:

I was going to suggest copying KGS's "no time cost for a pass within a
reasonable number of seconds" rule, but I see Erik just did that.
Well, I'll just second the suggestion. Unfortunately, the "reasonable
number of seconds" would probably have to be low, just so it doesn't
increase the game durations to unreasonable levels.


I like the idea too.
If one player delays the "PASS" it is only to the advantage of the
other player as he as more time to "ponder".
You could also limit the effects by adding 2 sconds (instead of 0.25)
for a PASS move.

Christoph
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

>> Better would be some kind of victory declaration.The program claims
>> victory - which means that it agrees that every move from now on (for
>> itself) is a pass move. It would be the counterpart to resignation -
>> with the provision that you give up all rights to defend yourself if you
>> are wrong.
>> 
>
> Won positions may still have forcing moves for the opponent (e.g.,
> atari-connect, etc.).
>
> I don't see a need for a separate victory declaration. If pass (and
> resign) are good enough for humans why would bots need more?
>   
I'm not seriously proposing this.It's just a crazy idea.



> Erik
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>   
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[steve uurtamo]

i like don's idea about using fischer time.  byo-yomi seems to be
the obvious solution to the problem (just make it a small byo-yomi time,
something like 5 seconds), but fischer time has some pretty magical
features that computers can easily take advantage of.  time management
should be quite a bit easier under fisher time, for instance, than with
something as complicated as byo-yomi, or something as delta-function as
absolute time.  even canadian time management is more complicated.

just a few nits...

> imagine 1 second per move, plus 2 seconds of net lag, in which case the
> programs have 1 second per move to think, plus 2+1+2 seconds between
> moves to ponder.

although it doesn't matter much, i doubt that anyone connecting their bot
to CGOS has 2 seconds of net lag per move, every move.  so it's kind've
a straw-man argument.  500-750ms is a reasonable upper-bound on the
average delay between two arbitrary machines when one is well-connected and
the other isn't in a third-world country.

> Also, if programs prolong the game as much as possible, it means that
> the next round of ALL programs will be delayed, and the more programs
> you have that deliberately refuse to resign, the greater the probability that 
> you
> will get two that, because of a failure on the part of the leader to
> correctly bring the game to a close, play a match that goes on
> basically forever. In that case, only a double-forfeit is sufficient
> -- switching to true absolute time limits would not be good enough,

by "basically forever" are you imagining a situation where legal moves are
played one after the other that both:

i) don't violate superko
ii) don't create a massive disadvantage for the person playing the move.

i guess i'm not imaginative enough today, but i am having trouble envisioning
a board where you would have both of these conditions hold *for both players*
for "basically forever" (where basically forever can be defined to be some huge
number of moves).

also, i don't think that it should delay anything for anyone else on CGOS, 
would it?
is this even a practical/pragmatic concern in tournaments?  have there been KGS
tournaments (or otherwise) that were held up "basically forever" because of 
extremely
unfortunate play between two opponents?

> because two players in a "Who can play stupid moves fastest?" battle
> could swamp the network and cause lag for programs playing real games.

this sounds wrong to me.  if the server can dequeue the packets at roughly
the same rate that they're coming in (and keep in mind that player B won't send
a new move packet until the server has already dealt with player A's move 
packet), the
packet sizes and bitrates involved should never swamp any reasonably 
well-connected
machine on a modern network.  you would need very many people doing this
simultaneously for it to be a real problem.  either that, or a very, very 
stupid protocol.

s.



  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Erik van der Werf]

On Jan 2, 2008 5:54 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
> Erik van der Werf wrote:
> > I'd propose something simpler:
> >
> > No time is deducted for pass.
> >
> > With this rule your program will only loose time when it absolutely
> > has to respond to the opponents move. In most games the winning
> > program can simply play until it has a sufficient number of
> > unconditionally alive stones on the board and then pass forever
> > without ever risking a loss on time.
> >
> This is not manageable and is also subject to manipulation.The
> server could wait forever to see if a move might be pass. The only
> reasonable way to implement this is to allow a liberal time margin for a
> pass move. For instance if your bot passes,  up to 5 seconds is
> "forgiven."

Yes, it's probably a good idea to set some kind of upper limit.


> I'm somewhat opposed to this idea.   The decision to pass is still a
> "considered decision" and I don't see why pass should be treated
> differently.

Normally, for rules using area-counting, pass is at best a worthless move.
Your rules shouldn't encourage pass-fights.


> Better would be some kind of victory declaration.The program claims
> victory - which means that it agrees that every move from now on (for
> itself) is a pass move. It would be the counterpart to resignation -
> with the provision that you give up all rights to defend yourself if you
> are wrong.

Won positions may still have forcing moves for the opponent (e.g.,
atari-connect, etc.).

I don't see a need for a separate victory declaration. If pass (and
resign) are good enough for humans why would bots need more?

Erik
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Erik van der Werf]

On Jan 2, 2008 5:46 PM, Eric Boesch <[EMAIL PROTECTED]> wrote:
>...
> Finally, I'm still not aware of any go programs that keep playing
> after they have obtained a dead lost position because the programmer
> wants them to do it. It's just easier to write a program that doesn't
> know when to resign than to write a program that does.
>
> On this point, I disagree with Erik. We get enough stupid games by
> accident that we don't need programs that play asinine games on
> purpose.

Well, actually I agree with you (hence the smiley), but in my opinion
this should be solved in the rules. The rules should not encourage
undesired behaviour. For this particular problem Byo-yomi is one
solution, not counting time for pass is another. For the latter, of
course, passing should still be done within a reasonable time but what
is reasonable may still be quite long because (1) it provides an
immediate opportunity to end the game and (2) if it is (ab)used before
the actual game is over it gives a big advantage to the opponent
(because he gets to move twice).

Erik
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

Erik van der Werf wrote:
> I'd propose something simpler:
>
> No time is deducted for pass.
>
> With this rule your program will only loose time when it absolutely
> has to respond to the opponents move. In most games the winning
> program can simply play until it has a sufficient number of
> unconditionally alive stones on the board and then pass forever
> without ever risking a loss on time.
>   
This is not manageable and is also subject to manipulation.The
server could wait forever to see if a move might be pass. The only
reasonable way to implement this is to allow a liberal time margin for a
pass move. For instance if your bot passes,  up to 5 seconds is
"forgiven."   

I'm somewhat opposed to this idea.   The decision to pass is still a
"considered decision" and I don't see why pass should be treated
differently.  

Better would be some kind of victory declaration.The program claims
victory - which means that it agrees that every move from now on (for
itself) is a pass move. It would be the counterpart to resignation -
with the provision that you give up all rights to defend yourself if you
are wrong.  

- Don



> Erik
>
>
> On Jan 2, 2008 3:02 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
>   
>> Of course it's also possible to implement the Fischer clock on CGOS.
>> Fischer clock is where you have a fixed time component (such as 5
>> minutes) but you also are given an increment - another fixed time
>> component that is added to your clock EACH MOVE.
>>
>> So it might be expressed as  "2 minutes + 5 seconds"  which means you
>> are given 2 minutes initially,  but you are also awarded 5 seconds per
>> move - whether you use it or not.It is simply added to your clock.
>>
>> I've always liked this kind of time control.   It prevents games lost
>> due to mad time control scrambles.   It makes the games feel more
>> traditional (like the old days when clocks were not used) because the
>> pressure of the clock has been reduced (although not eliminated.)
>>
>> There are some problems with this on CGOS:
>>
>>1.  I don't think GTP has  Fischer time mode.
>>2.  Not traditional in GO.
>>3.  Programs do not currently implement it.
>>4.  It doesn't really solve your problem.
>>
>> The fact that it's not traditional isn't a factor from my point of
>> view,  I am progressive about positive change.
>>
>> It doesn't solve your problem because you would still be cheated out of
>> 2 seconds per move - although it might be much easier for you to deal with.
>>
>> It would be simple to handle the GTP issues.   If your program could not
>> handle Fischer time some modes could be added to the client to help you
>> manage it.In the simplest case it would just report time remaining
>> and there could be modes that factor in the next N moves to this.
>>
>> - Don
>>
>>
>>
>>
>>
>> Peter Christopher wrote:
>> 
>>> I realize there are some legitimate reasons to have your bot play out
>>> the games on cgos until the bitter end.  Here I would like to present
>>> one reason why you may want to have your bot resign instead.  I live
>>> in the Philippines.  My ping from my computers here is usualy about
>>> .3-.4 seconds.  I do often put some bots on cgos from here, tend to be
>>> rated around 1600-1700.  Because of the long ping & the tromp-taylor
>>> rules, my bots often lose won games on time.  Playing from my computer
>>> here, I typically set a buffer around 45 seconds when the bot assumes
>>> the game is a won game & almost immediately plays filler moves.
>>> Nevertheless, with this buffer or even a larger buffer, the bot often
>>> captures massive groups, and at 2 moves per second (all network lag),
>>> the bot can't fill the whole board again & again, and if my bot passes
>>> & yours doesn't, that's also slow to fill the board.  The end result
>>> is that in your records, you may be testing your bot's new features
>>> and want to have an accurate elo rating to know whether it is working.
>>>  If your bot is playing my bot, and your bot doesn't resign lost
>>> games, you won't have an accurate rating of its new features.  Sorry
>>> for the inconvenience.  This is happening today quite a lot vs.
>>> challenger.  Some other days it's a different bot.  Just something to
>>> keep in mind.
>>> Peter
>>> ___
>>> computer-go mailing list
>>> computer-go@computer-go.org
>>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>>
>>>
>>>   
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>> 
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>   
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/comput

Re: [computer-go] Please have your bot resign, for your own good

[Eric Boesch]

In chess, playing the game out to the bitter end can be defensible,
but in go, it isn't. The meaning of the "end of the game" in go is
fluid, but it's not "when it's no longer possible to play a move". In
absolute time limit games, when significant per-move lag exists (which
is true in all human matches and some computer ones), it is impossible
to schedule correctly to deal with the possibility that the opponent
will continue playing for as long as possible after the game is
already over. Either you allocate too little time for the real game,
putting yourself at a disadvantage if you and your opponent play
reasonably, or you leave yourself without enough time to handle
unreasonable play. All go players know how to keep playing after the
game ends, but it's as childish and outside the spirit of the rules as
starting a no time limit game, realizing you have fallen behind, and
never returning to the board. In the eyes of most players, a time win
in a lost position well after the game has ended isn't even a
win-with-an-asterisk -- it's a dead loss, even moreso if the player
with the winning position played as quickly as lag would permit. This
is why byo yomi can actually shorten games: compared to absolute time,
it removes much of the incentive for children to keep playing after
the game is over.

All methods of compensating for net lag require some level of trust.
Even if a fraud-proof way to detect net lag existed, it would
interfere with time controls and scheduling. If it takes a second
before program B knows what move program A played, then that's a
second during which program A has better information about the game
than program B has. You can say that it hopefully averages out in the
wash, but the possibility that a program might gain an advantage from
its poor network connection is still there. Any compensation for net
lag at all means that a program that ponders gains a greater advantage
than the official time controls would suggest: imagine 1 second per
move, plus 2 seconds of net lag, in which case the programs have 1
second per move to think, plus 2+1+2 seconds between moves to ponder.
So I think Peter was right to direct his request to other programmers,
instead of asking Don to compensate for net lag.

I was going to suggest copying KGS's "no time cost for a pass within a
reasonable number of seconds" rule, but I see Erik just did that.
Well, I'll just second the suggestion. Unfortunately, the "reasonable
number of seconds" would probably have to be low, just so it doesn't
increase the game durations to unreasonable levels. One player passing
over and over while the other keeps playing dumb moves is a scenario
that is certain to occur over and over, and the only reason it's not a
bigger issue is that long delays by the passing player ought to be
infrequent.

With a little bit of go knowledge, it is possible for the server to
punish programs that play time-wasting moves, but if you can't count
on the players to be smart enough to know when they're wasting time,
that could mean assigning a loss to programs that are actually
winning. A simpler approach would be if the server just ended the game
as soon as it became statically solvable -- though exotic sekis aren't
statically solvable, so if they appeared then you'd have to fall back
on the two-passes-end-the-game rule. (In theory, superko can break
static analysis -- superko might forbid capturing a surrounded chain,
for example -- but in practice, I bet it never would.)

Finally, I'm still not aware of any go programs that keep playing
after they have obtained a dead lost position because the programmer
wants them to do it. It's just easier to write a program that doesn't
know when to resign than to write a program that does.

On this point, I disagree with Erik. We get enough stupid games by
accident that we don't need programs that play asinine games on
purpose. Peter already identified some reasons. Also, if programs
prolong the game as much as possible, it means that the next round of
ALL programs will be delayed, and the more programs you have that
deliberately refuse to resign, the greater the probability that you
will get two that, because of a failure on the part of the leader to
correctly bring the game to a close, play a match that goes on
basically forever. In that case, only a double-forfeit is sufficient
-- switching to true absolute time limits would not be good enough,
because two players in a "Who can play stupid moves fastest?" battle
could swamp the network and cause lag for programs playing real games.
One could even temporarily block the accounts so other programs can
continue while the programmers in question debug their broken
programs.

On Jan 2, 2008 8:22 AM, Don Dailey <[EMAIL PROTECTED]> wrote:
> Hi Peter,
>
> CGOS  doesn't count the first 1/4 second of thinking time and this could
> help a little.
>
> This isn't the same as Fischer time however because you are not given
> the time if it adds to your surplus.   It is design

Re: [computer-go] Please have your bot resign, for your own good

[Jason House]

On Jan 2, 2008 10:27 AM, Erik van der Werf <[EMAIL PROTECTED]> wrote:

> I'd propose something simpler:
>
> No time is deducted for pass.


That may be a bit too lax.  A bot that thinks for 5 seconds before passing
could delay all bots on the server.  I'd favor something in the same spirit
that limits such effects.  For example, increasing the quarter second
discount to a half second may be enough.

At what point do we stop trying to help the bots and just say that it's
their responsibility.  I don't believe other servers will be as tolerant as
CGOS.  I probably went overboard with my time management, but I collect
statistical descriptions of lag and set 4 sigma confidence bounds to avoid
loss on time.  In the previous KGS tournament spectators were nervous about
HouseBot leaving only 6 seconds left in *late* endgame.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

One of my bots will pass if the opponent passes first - if it's a win.  
Even if the opponent has dead stones still on the board.But of
course it won't pass if the Tromp Taylor score is not enough for the win.

- Don


Jason House wrote:
>  If your bot has enough points to win under Tromp Taylor scoring, why
> capture dead stones?  Passing is the fastest way to end the game in
> your favor.  That trick should limit your game length to something
> manageable.  I've been thinking that I should add that feature to my bot.
>
> I've also considered the exact opposite strategy...  When losing a
> game, aim to stress the opponent's time management (since it's the
> highest probability of victory).  That would include underhanded
> tricks like filling my own eyes.  I probably won't implement that, but
> it was an interesting thought.
>
> On Jan 1, 2008 11:57 PM, Peter Christopher <[EMAIL PROTECTED]
> > wrote:
>
> I realize there are some legitimate reasons to have your bot play out
> the games on cgos until the bitter end.  Here I would like to present
> one reason why you may want to have your bot resign instead.  I live
> in the Philippines.  My ping from my computers here is usualy about
> .3-.4 seconds.  I do often put some bots on cgos from here, tend to be
> rated around 1600-1700.  Because of the long ping & the tromp-taylor
> rules, my bots often lose won games on time.  Playing from my
> computer
> here, I typically set a buffer around 45 seconds when the bot assumes
> the game is a won game & almost immediately plays filler moves.
> Nevertheless, with this buffer or even a larger buffer, the bot often
> captures massive groups, and at 2 moves per second (all network lag),
> the bot can't fill the whole board again & again, and if my bot passes
> & yours doesn't, that's also slow to fill the board.  The end result
> is that in your records, you may be testing your bot's new features
> and want to have an accurate elo rating to know whether it is working.
>  If your bot is playing my bot, and your bot doesn't resign lost
> games, you won't have an accurate rating of its new features.  Sorry
> for the inconvenience.  This is happening today quite a lot vs.
> challenger.  Some other days it's a different bot.  Just something to
> keep in mind.
> Peter
> ___
> computer-go mailing list
> computer-go@computer-go.org 
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>
> 
>
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Erik van der Werf]

On Jan 2, 2008 4:18 PM, Jason House <[EMAIL PROTECTED]> wrote:
> I've also considered the exact opposite strategy...  When losing a game, aim
> to stress the opponent's time management (since it's the highest probability
> of victory).  That would include underhanded tricks like filling my own
> eyes.  I probably won't implement that, but it was an interesting thought.

Why not? If you bots logically applies CGOS rules it should only pass
in a losing position if it has absolutely no other legal move. Any
other way your bot will be playing sub-optimal ;-)

BTW filling an eye is not necessarily a bad move. It can, e.g., be
optimal in capturing races, and under superko it can be the tesuji
even when it sacrifices an unconditionally alive group.

E.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Erik van der Werf]

I'd propose something simpler:

No time is deducted for pass.

With this rule your program will only loose time when it absolutely
has to respond to the opponents move. In most games the winning
program can simply play until it has a sufficient number of
unconditionally alive stones on the board and then pass forever
without ever risking a loss on time.

Erik


On Jan 2, 2008 3:02 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
> Of course it's also possible to implement the Fischer clock on CGOS.
> Fischer clock is where you have a fixed time component (such as 5
> minutes) but you also are given an increment - another fixed time
> component that is added to your clock EACH MOVE.
>
> So it might be expressed as  "2 minutes + 5 seconds"  which means you
> are given 2 minutes initially,  but you are also awarded 5 seconds per
> move - whether you use it or not.It is simply added to your clock.
>
> I've always liked this kind of time control.   It prevents games lost
> due to mad time control scrambles.   It makes the games feel more
> traditional (like the old days when clocks were not used) because the
> pressure of the clock has been reduced (although not eliminated.)
>
> There are some problems with this on CGOS:
>
>1.  I don't think GTP has  Fischer time mode.
>2.  Not traditional in GO.
>3.  Programs do not currently implement it.
>4.  It doesn't really solve your problem.
>
> The fact that it's not traditional isn't a factor from my point of
> view,  I am progressive about positive change.
>
> It doesn't solve your problem because you would still be cheated out of
> 2 seconds per move - although it might be much easier for you to deal with.
>
> It would be simple to handle the GTP issues.   If your program could not
> handle Fischer time some modes could be added to the client to help you
> manage it.In the simplest case it would just report time remaining
> and there could be modes that factor in the next N moves to this.
>
> - Don
>
>
>
>
>
> Peter Christopher wrote:
> > I realize there are some legitimate reasons to have your bot play out
> > the games on cgos until the bitter end.  Here I would like to present
> > one reason why you may want to have your bot resign instead.  I live
> > in the Philippines.  My ping from my computers here is usualy about
> > .3-.4 seconds.  I do often put some bots on cgos from here, tend to be
> > rated around 1600-1700.  Because of the long ping & the tromp-taylor
> > rules, my bots often lose won games on time.  Playing from my computer
> > here, I typically set a buffer around 45 seconds when the bot assumes
> > the game is a won game & almost immediately plays filler moves.
> > Nevertheless, with this buffer or even a larger buffer, the bot often
> > captures massive groups, and at 2 moves per second (all network lag),
> > the bot can't fill the whole board again & again, and if my bot passes
> > & yours doesn't, that's also slow to fill the board.  The end result
> > is that in your records, you may be testing your bot's new features
> > and want to have an accurate elo rating to know whether it is working.
> >  If your bot is playing my bot, and your bot doesn't resign lost
> > games, you won't have an accurate rating of its new features.  Sorry
> > for the inconvenience.  This is happening today quite a lot vs.
> > challenger.  Some other days it's a different bot.  Just something to
> > keep in mind.
> > Peter
> > ___
> > computer-go mailing list
> > computer-go@computer-go.org
> > http://www.computer-go.org/mailman/listinfo/computer-go/
> >
> >
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Jason House]

 If your bot has enough points to win under Tromp Taylor scoring, why
capture dead stones?  Passing is the fastest way to end the game in your
favor.  That trick should limit your game length to something manageable.
I've been thinking that I should add that feature to my bot.

I've also considered the exact opposite strategy...  When losing a game, aim
to stress the opponent's time management (since it's the highest probability
of victory).  That would include underhanded tricks like filling my own
eyes.  I probably won't implement that, but it was an interesting thought.

On Jan 1, 2008 11:57 PM, Peter Christopher <[EMAIL PROTECTED]>
wrote:

> I realize there are some legitimate reasons to have your bot play out
> the games on cgos until the bitter end.  Here I would like to present
> one reason why you may want to have your bot resign instead.  I live
> in the Philippines.  My ping from my computers here is usualy about
> .3-.4 seconds.  I do often put some bots on cgos from here, tend to be
> rated around 1600-1700.  Because of the long ping & the tromp-taylor
> rules, my bots often lose won games on time.  Playing from my computer
> here, I typically set a buffer around 45 seconds when the bot assumes
> the game is a won game & almost immediately plays filler moves.
> Nevertheless, with this buffer or even a larger buffer, the bot often
> captures massive groups, and at 2 moves per second (all network lag),
> the bot can't fill the whole board again & again, and if my bot passes
> & yours doesn't, that's also slow to fill the board.  The end result
> is that in your records, you may be testing your bot's new features
> and want to have an accurate elo rating to know whether it is working.
>  If your bot is playing my bot, and your bot doesn't resign lost
> games, you won't have an accurate rating of its new features.  Sorry
> for the inconvenience.  This is happening today quite a lot vs.
> challenger.  Some other days it's a different bot.  Just something to
> keep in mind.
> Peter
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

Of course it's also possible to implement the Fischer clock on CGOS.   
Fischer clock is where you have a fixed time component (such as 5
minutes) but you also are given an increment - another fixed time
component that is added to your clock EACH MOVE.   

So it might be expressed as  "2 minutes + 5 seconds"  which means you
are given 2 minutes initially,  but you are also awarded 5 seconds per
move - whether you use it or not.It is simply added to your clock.

I've always liked this kind of time control.   It prevents games lost
due to mad time control scrambles.   It makes the games feel more
traditional (like the old days when clocks were not used) because the
pressure of the clock has been reduced (although not eliminated.) 

There are some problems with this on CGOS:

   1.  I don't think GTP has  Fischer time mode. 
   2.  Not traditional in GO.  
   3.  Programs do not currently implement it.
   4.  It doesn't really solve your problem. 

The fact that it's not traditional isn't a factor from my point of
view,  I am progressive about positive change.

It doesn't solve your problem because you would still be cheated out of
2 seconds per move - although it might be much easier for you to deal with.

It would be simple to handle the GTP issues.   If your program could not
handle Fischer time some modes could be added to the client to help you
manage it.In the simplest case it would just report time remaining 
and there could be modes that factor in the next N moves to this.   

- Don

 


Peter Christopher wrote:
> I realize there are some legitimate reasons to have your bot play out
> the games on cgos until the bitter end.  Here I would like to present
> one reason why you may want to have your bot resign instead.  I live
> in the Philippines.  My ping from my computers here is usualy about
> .3-.4 seconds.  I do often put some bots on cgos from here, tend to be
> rated around 1600-1700.  Because of the long ping & the tromp-taylor
> rules, my bots often lose won games on time.  Playing from my computer
> here, I typically set a buffer around 45 seconds when the bot assumes
> the game is a won game & almost immediately plays filler moves.
> Nevertheless, with this buffer or even a larger buffer, the bot often
> captures massive groups, and at 2 moves per second (all network lag),
> the bot can't fill the whole board again & again, and if my bot passes
> & yours doesn't, that's also slow to fill the board.  The end result
> is that in your records, you may be testing your bot's new features
> and want to have an accurate elo rating to know whether it is working.
>  If your bot is playing my bot, and your bot doesn't resign lost
> games, you won't have an accurate rating of its new features.  Sorry
> for the inconvenience.  This is happening today quite a lot vs.
> challenger.  Some other days it's a different bot.  Just something to
> keep in mind.
> Peter
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>   
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Please have your bot resign, for your own good

[Don Dailey]

Hi Peter,

CGOS  doesn't count the first 1/4 second of thinking time and this could
help a little. 

This isn't the same as Fischer time however because you are not given
the time if it adds to your surplus.   It is designed so that if you
play fast enough (less than 1/4 second per move) you will not lose time
on the clock provided your network is not too slow.Apparently that
is not enough in your case. 

I agree with resigning - it's the most friendly and cooperative way to
play.   I recently saw my bot win a dead lost game on time because I
have not yet put resignation in it. 

Actually,  I would personally not resign if I thought the opponent might
lose on time - I consider it part of the game.My bot would play
stronger if I took more time to win games too and I feel it's completely
fair to penalize programs that spend too much time getting a won game
and then expect you to resign so that they do not lose. 

However, yours is a special case - you have no control over the network
lag factor and it's not fair for you to lose this way.  

I have heard of protocols that attempt to deal fairly with network lag -
but I don't know how they work.   I don't know how to design one that is
not subject to tampering with.

I wish I knew how to deal with your problem in a fair way.   But then on
the other hand some people have very fast computers - which might also
seem unfair.If your computer is twice as fast as mine,  you are
effectively getting twice as much thinking time.   So CGOS is just
what it is.   You do the best with the "equipment" you have.   

I will think about the problem.   I would like network lag not to be an
issue, but it seems like it will always be.   How does KGS deal with
this? What do you do when you play on KGS?

- Don



Peter Christopher wrote:
> I realize there are some legitimate reasons to have your bot play out
> the games on cgos until the bitter end.  Here I would like to present
> one reason why you may want to have your bot resign instead.  I live
> in the Philippines.  My ping from my computers here is usualy about
> .3-.4 seconds.  I do often put some bots on cgos from here, tend to be
> rated around 1600-1700.  Because of the long ping & the tromp-taylor
> rules, my bots often lose won games on time.  Playing from my computer
> here, I typically set a buffer around 45 seconds when the bot assumes
> the game is a won game & almost immediately plays filler moves.
> Nevertheless, with this buffer or even a larger buffer, the bot often
> captures massive groups, and at 2 moves per second (all network lag),
> the bot can't fill the whole board again & again, and if my bot passes
> & yours doesn't, that's also slow to fill the board.  The end result
> is that in your records, you may be testing your bot's new features
> and want to have an accurate elo rating to know whether it is working.
>  If your bot is playing my bot, and your bot doesn't resign lost
> games, you won't have an accurate rating of its new features.  Sorry
> for the inconvenience.  This is happening today quite a lot vs.
> challenger.  Some other days it's a different bot.  Just something to
> keep in mind.
> Peter
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>   
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/