I am currently adding code to ermintrude's ICC interface to allow her to offer and accept draws from opponents. This is partly motivated by consideration for human players who reach an obviously drawn position but are currently made to force a repetition in order to claim the draw, but mostly from the embarassment of having seen ermintrude lose from drawn positions by running out of time making futile moves.
mambofish wrote:I am currently adding code to ermintrude's ICC interface to allow her to offer and accept draws from opponents. This is partly motivated by consideration for human players who reach an obviously drawn position but are currently made to force a repetition in order to claim the draw, but mostly from the embarassment of having seen ermintrude lose from drawn positions by running out of time making futile moves.
boolean accept_draw(score) {
if (game.length > 30) {
if (score >= -50 && score <= 50 && opponent_rating - computer_rating > 100)
return true;
if (abs(score - average_score_last_20_plies) < 50) {
if (computer_in_time_trouble)
return true;
if (opponent_in_time_trouble)
return false;
return (opponent_rating > computer_rating);
}
}
return false;
}
Comments welcome!
Regards
Vince
Crafty has been offering/accepting draws for 10+ years. You can look at its code to see what I do. The only thing is that I have a cycle counter so that I have to get N consecutive draw scores before I offer a draw, to (1) be sure it is likely drawn and (2) avoid being obnoxious and offering a draw every move. Accepting draws requires that the current search return a draw score before accepting, to make sure the opponent didn't play a blunder in a drawn position and then quickly offer a draw before crafty moves.
mambofish wrote:I am currently adding code to ermintrude's ICC interface to allow her to offer and accept draws from opponents. This is partly motivated by consideration for human players who reach an obviously drawn position but are currently made to force a repetition in order to claim the draw, but mostly from the embarassment of having seen ermintrude lose from drawn positions by running out of time making futile moves.
Regards
Vince
If your engine lose on time the obvious solution is to fix your time management.
offering and accepting a draw is not going to help if the opponent does not want a draw.
Part of the reason for wanting something a bit more complex is that ermintrude's draw-recognition code is nowhere near complete: things like locked centre endgames with opposite colour bishops can be pretty hard to recognise accurately. And it can be really irksome for humans to reach a position which they know is drawn, but which the computer - perhaps because of a significant material advantage - refuses to contemplate as a draw.
So obviously, the draw-recognition code needs to be improved but this takes considerable time. Because my engine is not yet so strong - round 2200/2300 on ICC - many people play it (over 10,000 games since December 2006!). This is good for them, and good for me - it highlights weak points in the engine - including draw recognition for example. I don't want to put them off because of those weaknesses, but neither on the other hand, do I want to throw away points unnecessarily!
Ermintrude's time management is pretty good actually - a little conservative even.
But in a 3 0 game, which is dead drawn, when the opponent has offered the draw and the engine is too stupid to accept, no amount of time management will fix the problem; eventually the engine will run out of time and lose. This is a situation I want to try to avoid, as its the only one where the engine ever gets flagged in practice.
Thanks very much for the suggestions. Actually I haven't got around to thinking about offering draws in any detail, as I feel its likely to be needed less often. However, your draw-counter looks like a very sensible idea. I'll take a peek at Crafty's code, thanks.
And of course the engine must do a search first as you say. My ICC interface code is completely separate from the engine code, so this draw management stuff can be handled pretty seamlessly I hope - the engine won't even know the opponent is requesting a draw.
As for resigning - as Bent Larsen said - "nobody ever won by resigning", although someone else (I forget who) said you should only ever resign when everybody in the room knows your next move...! Against a human I don't think I'd get the engine to resign unless mate was 8 ply or less away, humans do blunder so ... Against a computer its a different matter, I suppose you might as well resign the moment you post a "getting mated" score
Ermintrude's time management is pretty good actually - a little conservative even.
But in a 3 0 game, which is dead drawn, when the opponent has offered the draw and the engine is too stupid to accept, no amount of time management will fix the problem; eventually the engine will run out of time and lose. This is a situation I want to try to avoid, as its the only one where the engine ever gets flagged in practice.
Vince
This is simply not correct.
Note that I do not care about 3 0 time control but it is clearly possible not to lose on time by playing faster when the engine is in time trouble.
Ermintrude's time management is pretty good actually - a little conservative even.
But in a 3 0 game, which is dead drawn, when the opponent has offered the draw and the engine is too stupid to accept, no amount of time management will fix the problem; eventually the engine will run out of time and lose. This is a situation I want to try to avoid, as its the only one where the engine ever gets flagged in practice.
Vince
This is simply not correct.
Note that I do not care about 3 0 time control but it is clearly possible not to lose on time by playing faster when the engine is in time trouble.
Uri
And you're simply wrong here, because this topic is about ICS games.
Thanks very much for the suggestions. Actually I haven't got around to thinking about offering draws in any detail, as I feel its likely to be needed less often. However, your draw-counter looks like a very sensible idea. I'll take a peek at Crafty's code, thanks.
And of course the engine must do a search first as you say. My ICC interface code is completely separate from the engine code, so this draw management stuff can be handled pretty seamlessly I hope - the engine won't even know the opponent is requesting a draw.
As for resigning - as Bent Larsen said - "nobody ever won by resigning", although someone else (I forget who) said you should only ever resign when everybody in the room knows your next move...! Against a human I don't think I'd get the engine to resign unless mate was 8 ply or less away, humans do blunder so ... Against a computer its a different matter, I suppose you might as well resign the moment you post a "getting mated" score
Vince
I added the ability to accept and offer draws, and to resign, purely to attract GM players. In the middle 90's, when I started to play on ICC, they complained bitterly as no program would offer/accept draws nor would they resign in hopeless situations.
I offered a dynamic facility that will resign sooner against GM players, not quite as quickly against IM players, etc. And the same for draw offers. But in real events against computers I turn it off. Nobody gets tired and I have seen programs blow a +12.00 lead in a game and draw or even lose from such positions. May as well make them prove they can win those games..
... Against a computer its a different matter, I suppose you might as well resign the moment you post a "getting mated" score
