Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: new autoplayer interface standard

Author: Dan Newman

Date: 13:02:49 09/18/98

Go up one level in this thread


On September 18, 1998 at 04:45:51, Roberto Waldteufel wrote:

>
>On September 17, 1998 at 15:46:28, Dan Homan wrote:
>
>>On September 17, 1998 at 15:11:58, Dan Newman wrote:
>>
>>>On September 17, 1998 at 14:21:45, Robert Hyatt wrote:
>>>
>>>>
>>>>I bend the rules here.  You are supposed to make a move, offer a draw, and hit
>>>>the clock.  I do all *three* simultaneously... because I send a move, then I
>>>>send "draw?" and hit the clock, and all three occur within microseconds of each
>>>>other so that they are effectively done at the same instant.  We could add a
>>>>"press clock" command but that seems stupid.  But it would fix the protocol as
>>>>follows:
>>>>
>>>>move Nf7+
>>>>draw
>>>>press clock
>>>>
>>>>In this protocol, I don't think it matters.  Programs won't (I hope, and this
>>>>could be an issue maybe) spew out a zillion "draw" offers while the other side
>>>>is thinking.  That *could* affect the other program obviously.  ICC solves this
>>>>for us, but the protocol wouldn't unless we address it.  We could disallow draw
>>>>offers without intervening "move xxx" commands to avoid any possible abuse?
>>>
>>>I agree about "press clock"; it would be there to solve only this one
>>>problem and yet would be required after every move...  Perhaps the interfaces
>>>could be written to suppress multiple draw offers--so the hurt would only
>>>be on the machine of the abuser.  (This assumes all interface programmers
>>>are pure of heart and mind of course.)
>>>
>>>-Dan.
>>
>>
>>Why not simply have the interface only pass at most one draw offer following
>>each move, subsequent draw offers are simply ignored by the interface?
>>
>> - Dan
>
>May I suggest my own idea here, which is similar to yours. I would create an
>optional second parameter for the move command which allowed for a draw offer to
>be appended to a move, so a command sent from an engine to its interface might
>look like this:
>
>move Rf7 draw?
>
>where "move" is the command, "Rf7" is the compulsory move parameter and "draw?"
>is the optional extra parameter
>
>This way we have some parsimony, ie we make use of the existing commands rather
>than introduce new ones, while at the same time restricting draw offers to one
>per move.
>
>Best wishes,
>Roberto

I like this idea the best so far.  The command could even be passed to
the other engine unchanged.  It also sort of prevents hammering of the
opponent with multiple draw offers, and we would no longer have to worry
about what order the move and draw offer should be sent.

Also, the opponent would know simultaneously about the move and the
draw offer.  (Imagine that engine "A" has been pondering for a long
time on the move Rg3 and then the move Rg3 comes in from engine "B",
followed a few milliseconds later by a draw offer--but it's too late:
engine "A" has already responded with a move--effectively a rejection
of the draw offer.  Now "A" gets the draw offer while pondering its
next move, but "B" thinks the draw offer was rejected...a big mess.)

This one has my vote.

-Dan.



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.