Resign annoyance

[hgm]

Similar to the problem of non-atomic draw claims, there is a timing issue in loss claims (= resigning) too. Most engine do this in a very annoying way, still sending a move before they resign:

move Kh1
0-1 {white resigns}

But this causes the move to be relayed to the opponent (as the GUI cannot afford to wait an indeterminate time after every move to see if it happens to be followed by a resignation). So when the resignation comes in, the opponent is already thinking. Many engines do not allow their thinking to be interrupted, and for engines that do not support 'ping' there is not even a way to probe when they are done thinking. This cause big problems in matches, as the GUI does not know when it is safe to start a new game. The superfluous move can fall in the next game, be mistaken for a true move, and lead to illegal moves later. Even when you are not playing in match mode, but restart the GUI with new engine processes, or just start new engine processes, the other engine might still hang some time, using CPU, as the killing process in Windows is not always reliable.

I think engines should resign before giving their move. (i.e. not give the move at all.) What is the point of giving a move when you resign? Apparently you failed low and no move was worth playing to continue the game.

So just like with draw offers, also here holds:
only resign in your own time!

I think I should make WinBoard hold up resignations that are handed in when the opponent's clock is running until after that opponent produced his move.

(Note that this is different from claiming checkmtes: after

move Qg2#
0-1 {white is checkmated}

the opponent wil not start thinking on a move after receiving Qg2, as he will (presumably) see that he is checkmated too.)

[bob]

Similar to the problem of non-atomic draw claims, there is a timing issue in loss claims (= resigning) too. Most engine do this in a very annoying way, still sending a move before they resign:

move Kh1
0-1 {white resigns}

But this causes the move to be relayed to the opponent (as the GUI cannot afford to wait an indeterminate time after every move to see if it happens to be followed by a resignation). So when the resignation comes in, the opponent is already thinking. Many engines do not allow their thinking to be interrupted, and for engines that do not support 'ping' there is not even a way to probe when they are done thinking. This cause big problems in matches, as the GUI does not know when it is safe to start a new game. The superfluous move can fall in the next game, be mistaken for a true move, and lead to illegal moves later. Even when you are not playing in match mode, but restart the GUI with new engine processes, or just start new engine processes, the other engine might still hang some time, using CPU, as the killing process in Windows is not always reliable.

I think engines should resign before giving their move. (i.e. not give the move at all.) What is the point of giving a move when you resign? Apparently you failed low and no move was worth playing to continue the game.

So just like with draw offers, also here holds:
only resign in your own time!

I think I should make WinBoard hold up resignations that are handed in when the opponent's clock is running until after that opponent produced his move.

(Note that this is different from claiming checkmtes: after

move Qg2#
0-1 {white is checkmated}

the opponent wil not start thinking on a move after receiving Qg2, as he will (presumably) see that he is checkmated too.)

The more I think about it the more I like the idea of a new command "stop clock" or "press clock" or something similar to indicate that we are through with our move. Making a move and then resigning is not incorrect. Many games end like this, which can be verified by looking at PGN collections. In fact, I am not sure it is not allowable to resign on my opponent's time. I watched an IM make a move, hit the clock, and after about a minute's thought, he tipped his king over and resigned, while his opponent was thinking, after he realized he had just made a horrible blunder.

I think the best approach is to simply kill both engines when a game ends, start them back up, and play the next game. This avoids a messy re-initialization that can introduce strange bugs, and solves the problem you mention. I always test like this and don't depend on "new" to reset things anyway. That gets rid of the timing issues dealing with "dangling moves" and such. Kill the engine, close the pipe, and re-start everything. No way for an extra move (which actually might be legal, in fact) to slip in and screw up a result.

[JVMerlino]

I think the best approach is to simply kill both engines when a game ends, start them back up, and play the next game. This avoids a messy re-initialization that can introduce strange bugs, and solves the problem you mention. I always test like this and don't depend on "new" to reset things anyway. That gets rid of the timing issues dealing with "dangling moves" and such. Kill the engine, close the pipe, and re-start everything. No way for an extra move (which actually might be legal, in fact) to slip in and screw up a result.

Doesn't "reuse=0" cover this, if you want your engine to be restarted for every game? Although I must admit I don't understand the benefit of "reuse=1", except for a few seconds while engines reinitialize between games.

jm

[bob]

I think the best approach is to simply kill both engines when a game ends, start them back up, and play the next game. This avoids a messy re-initialization that can introduce strange bugs, and solves the problem you mention. I always test like this and don't depend on "new" to reset things anyway. That gets rid of the timing issues dealing with "dangling moves" and such. Kill the engine, close the pipe, and re-start everything. No way for an extra move (which actually might be legal, in fact) to slip in and screw up a result.

Doesn't "reuse=0" cover this, if you want your engine to be restarted for every game? Although I must admit I don't understand the benefit of "reuse=1", except for a few seconds while engines reinitialize between games.

jm

Yes, it does, although I am not sure all GUIs pay attention to that. I think the only real benefit is playing very fast games and using 5-6 piece endgame tables, which take a long time to initialize if you have slow disks. I think the risk far outweighs the benefit however.

[MattieShoes]

One could sidestep the issue in engine-engine matches by simply not issuing the resign until that player is on-move again. Wait until winning player issues move, then send the resign to it. It's far from ideal but it removes the chance getting a move from one game inserted into another and causing issues. The two engines would then produce slightly different PGNs, but the results should be the same...

[bob]

One could sidestep the issue in engine-engine matches by simply not issuing the resign until that player is on-move again. Wait until winning player issues move, then send the resign to it. It's far from ideal but it removes the chance getting a move from one game inserted into another and causing issues. The two engines would then produce slightly different PGNs, but the results should be the same...

I was under the impression that this is exactly what "new" does. No matter what an engine is doing, it is supposed to stop, reset the board to the starting position, etc... The problem lies in the pipes being used. They are asynchronous and introduce race conditions such as the GUI sending a new, while the engine sends a move. I like the reuse=0 option so that no "new" is needed. Send a "quit", give the engine a second to quit (to do book learning or whatever), then kill the process, destroy the pipes, and start over. No races, no extraneous leftover I/O, etc...

That's what I do on my cluster referee for testing. Very early on I had lots of odd results, where an engine would send a move like Nf3, I would send it a move, then tell it to reset and play white, and then think it had played Nf3 as its first move. Opponent would reply, and eventually one side would hang because of the erroneous first move I found.

[michiguel]

Similar to the problem of non-atomic draw claims, there is a timing issue in loss claims (= resigning) too. Most engine do this in a very annoying way, still sending a move before they resign:

move Kh1
0-1 {white resigns}

But this causes the move to be relayed to the opponent (as the GUI cannot afford to wait an indeterminate time after every move to see if it happens to be followed by a resignation). So when the resignation comes in, the opponent is already thinking. Many engines do not allow their thinking to be interrupted, and for engines that do not support 'ping' there is not even a way to probe when they are done thinking. This cause big problems in matches, as the GUI does not know when it is safe to start a new game. The superfluous move can fall in the next game, be mistaken for a true move, and lead to illegal moves later. Even when you are not playing in match mode, but restart the GUI with new engine processes, or just start new engine processes, the other engine might still hang some time, using CPU, as the killing process in Windows is not always reliable.

I think engines should resign before giving their move. (i.e. not give the move at all.) What is the point of giving a move when you resign? Apparently you failed low and no move was worth playing to continue the game.

So just like with draw offers, also here holds:
only resign in your own time!

I think I should make WinBoard hold up resignations that are handed in when the opponent's clock is running until after that opponent produced his move.

Yes, that should do it. Note that this is not a problem of the engines that resign after moving (which is perfectly legal in chess). It is a problem of non-responsive engines. I think you should hold the resignation, unless the winning engine can use ping and the GUI feels comfortable about communicating properly.

In addition, if a human is playing an engine, it is not so rare to resign before the engine moves (i.e. after the human moved). Win/Xboard has to be prepared for that.

Miguel

(Note that this is different from claiming checkmtes: after

move Qg2#
0-1 {white is checkmated}

the opponent wil not start thinking on a move after receiving Qg2, as he will (presumably) see that he is checkmated too.)

[michiguel]

I think the best approach is to simply kill both engines when a game ends, start them back up, and play the next game. This avoids a messy re-initialization that can introduce strange bugs, and solves the problem you mention. I always test like this and don't depend on "new" to reset things anyway. That gets rid of the timing issues dealing with "dangling moves" and such. Kill the engine, close the pipe, and re-start everything. No way for an extra move (which actually might be legal, in fact) to slip in and screw up a result.

Doesn't "reuse=0" cover this, if you want your engine to be restarted for every game? Although I must admit I don't understand the benefit of "reuse=1", except for a few seconds while engines reinitialize between games.

jm

Yes, it does, although I am not sure all GUIs pay attention to that. I think the only real benefit is playing very fast games and using 5-6 piece endgame tables, which take a long time to initialize if you have slow disks. I think the risk far outweighs the benefit however.

I am digressing, but why does it take long to initialize 5 pc EGTBs? How long? Gaviota's own TBs take not time in the start up. Is it because Gaviota's format is not compressed? In the Nalimov's format is it necessary to download some sort of indexing tables or create them on the startup?

Miguel

[Matthias Gemuh]

I think the best approach is to simply kill both engines when a game ends, start them back up, and play the next game. This avoids a messy re-initialization that can introduce strange bugs, and solves the problem you mention.

That is how ChessGUI works, even in a 2-engine match or testsuite.
No engine gets "reused".

Matthias.

[bob]

I think the best approach is to simply kill both engines when a game ends, start them back up, and play the next game. This avoids a messy re-initialization that can introduce strange bugs, and solves the problem you mention. I always test like this and don't depend on "new" to reset things anyway. That gets rid of the timing issues dealing with "dangling moves" and such. Kill the engine, close the pipe, and re-start everything. No way for an extra move (which actually might be legal, in fact) to slip in and screw up a result.

Doesn't "reuse=0" cover this, if you want your engine to be restarted for every game? Although I must admit I don't understand the benefit of "reuse=1", except for a few seconds while engines reinitialize between games.

jm

Yes, it does, although I am not sure all GUIs pay attention to that. I think the only real benefit is playing very fast games and using 5-6 piece endgame tables, which take a long time to initialize if you have slow disks. I think the risk far outweighs the benefit however.

I am digressing, but why does it take long to initialize 5 pc EGTBs? How long? Gaviota's own TBs take not time in the start up. Is it because Gaviota's format is not compressed? In the Nalimov's format is it necessary to download some sort of indexing tables or create them on the startup?

Miguel

That's the reason. The TBs are decompressed on the fly. In chunks. There are large numbers of "index points" so that you get to the beginning of a "chunk" where you have to be to start the decompression process. For 5 piece files the decompression indices are nearly 15mb in size. For the 6's, this goes to hundreds of megabytes of data. On fast drives, the 5's initialize almost instantly, on slow dirves, they take longer. If you use all the 6's, it can take a long time to set up all the indices. >15 seconds on my 15K scsi drives using raid-0.