UCI protocol issue

[jdart]

I have had a bug report that involved the following scenario when running a match with UCI and ponder on:

1. UCI GUI sends a move list whose terminal position is a repetition draw (last move is the 3rd repetition).

2. UCI gives the engine a "go ponder" command.

3. The engine does the search but because it is a draw before any move is made, no move is returned.

4. Other engine sends a move and it is not the predicted one and not one that would cause a repetition draw.

5. UCI sends "stop"

6. Now the UCI protocol requires that a "bestmove" command be sent from the engine. But the engine has no move to send. What is correct behavior in this case? (This could also occur in other situations - for example move being pondered leads to a stalemate or mate).

--Jon

[hgm]

bestmove 0000

A GUI should have no need to examine the move after a ponder miss anyway, so it would probably also work if you would send "bestmove f*ck off".

For this reason it is more interesting when the GUI would send you a move list that is a rep draw, not for pondering but for go-movestogo. Because then it will take the bestmove serious. If you solved that, the ponder thing should logically follow.

(IMO "bestmove 0000" should also be used here, to claim the draw.)

[jdart]

A GUI should have no need to examine the move

.

That is true but I am not sure all GUIs will ignore it.

IMO this really shows up a fault in the protocol design. "bestmove" means both "I have found a move and this is it" and also "I got your last stop command". IMO those should ideally be separate commands from the engine.

For this reason it is more interesting when the GUI would send you a move list that is a rep draw

I think GUIs usually don't do this because they adjudicate the game a draw.

--Jon

[zamar]

I have had a bug report that involved the following scenario when running a match with UCI and ponder on:

1. UCI GUI sends a move list whose terminal position is a repetition draw (last move is the 3rd repetition).

2. UCI gives the engine a "go ponder" command.

3. The engine does the search but because it is a draw before any move is made, no move is returned.

4. Other engine sends a move and it is not the predicted one and not one that would cause a repetition draw.

5. UCI sends "stop"

6. Now the UCI protocol requires that a "bestmove" command be sent from the engine. But the engine has no move to send. What is correct behavior in this case? (This could also occur in other situations - for example move being pondered leads to a stalemate or mate).

--Jon

Hi Jon,

This is a grey area in UCI protocal.

- It doesn't really make sense for GUI to ask engine to think on position which will be automatically adjudicated as draw.

- But if they do, an engine can return whatever it wants, e.g.
bestmove none

[Michel]

I don't think there is a "grey area".

(1) In the UCI protocol the GUI should never ask the engine to search a position in which there is no legal move. If it does then it is a bug in the GUI.

(2) 3 fold rep draws and 50 move rule draws only materialize when they are claimed. Since the engine can not claim draw under the UCI protocol it should just search the position and return the best move it finds.

[jdart]

I don't think there is a "grey area".

(1) In the UCI protocol the GUI should never ask the engine to search a position in which there is no legal move. If it does then it is a bug in the GUI.

GUI here was Arena and it does send move lists that terminate in a draw by rule. IMO this is legitimate in this case where a ponder search is being initiated.

(2) 3 fold rep draws and 50 move rule draws only materialize when they are claimed. Since the engine can not claim draw under the UCI protocol it should just search the position and return the best move it finds.

Again, this is a ponder search we are talking about, so there is no issue about claiming the draw. The ponder move wasn't even made by the opponent so no draw appeared in the sequence of actual game moves.

[Michel]

GUI here was Arena and it does send move lists that terminate in a draw by rule. IMO this is legitimate in this case where a ponder search is being initiated.

You mean something like draw by insufficient material? This is indeed an automatic draw and I think it is a minor bug in Arena (one of many) that it asks the engine to search in such a position (ponder or not). But this being said in this case there is no problem returning a legal move. So no need to return something like bestmove 0000.

Again, this is a ponder search we are talking about, so there is no issue about claiming the draw.

I understood that. But my opinion stands. The engine should just search the position given to it by the GUI and ignore the 3 fold rep draw.

[jdart]

I understood that. But my opinion stands. The engine should just search the position given to it by the GUI and ignore the 3 fold rep draw.

That is indeed another possible fix at least in this case. If however the GUI sends a move string that ends in stalemate you still need to send something via bestmove, otherwise the GUI will think the engine is hung. (I do not know if any GUIs actually do this - I can investigate it though).

--Jon

[Don]

GUI here was Arena and it does send move lists that terminate in a draw by rule. IMO this is legitimate in this case where a ponder search is being initiated.

You mean something like draw by insufficient material? This is indeed an automatic draw and I think it is a minor bug in Arena (one of many) that it asks the engine to search in such a position (ponder or not). But this being said in this case there is no problem returning a legal move. So no need to return something like bestmove 0000.

Again, this is a ponder search we are talking about, so there is no issue about claiming the draw.

I understood that. But my opinion stands. The engine should just search the position given to it by the GUI and ignore the 3 fold rep draw.

What happens when asked to search a ponder move that delivers mate?

If there is a legal move possible and you are asked what the best move is you should return one of those legal moves. Claiming a win or draw or offering one is not in the UCI protocol.

Many, if not most chess programs will return a draw score even on 1 match - but it is not understand to be a "draw claim", that is something we leave to the GUI. So if there is no legal move we return "0000", otherwise we always return the move the computer thinks is best - and refusing to move is not an option. At least not with UCI.

In my opinion UCI is way to loosely defined and could be greatly improved by defining what specific behavior is expected under certain situations. And the protocol creator should create a test harness - a program which will run your program through a test to see if it is conforming to the protocol. There needs to be a PATH data type for when files are specified and a few other little glitches need to be corrected. I would also like to see some features standardized such as "Threads".

There is the issue of WHEN you can set an option. GUI's are not consistent about this. Someone reported a bug where they changed the hash table size or number of threads or something during the search (evidently some GUI's allow this) and Komodo will try to honor the command during the search. That's a bug in Komodo, but I assumed that something like this would be forbidden by the protocol - after all the primary appeal of UCI is to take away the burden of GUI issues and implementation away from the engine author. Even if the answer is that the engine should support these changes at any time - I would be ok with that as long as it's specified as behavior you should expect.

UCI is a great protocol, I just think it has some warts that could and should be corrected.

This is where HG comes in with a pitch for the winboard protocol - please don't do that HG I know that you are chomping at the bit right now.

[hgm]

... - and refusing to move is not an option. At least not with UCI.

I think you make that up entirely yourself. The protocol specs don't say that at all.

What they do explicitly say is that the engine can send 0000 as a move, to be understood as a null move. It does NOT say there are any restrictions to its use (like only in the pv info). In fact it does not even specify that moves sent by the engine have to be legal moves anywhere.

If an engine sends "bestmove 0000", with a score info of 0 cp (or -0 mate) , it is totally conforming to the UCI specs. If a GUI cannot handle that, this GUI is not UCI compliant...