UCI nullmove

[hgm]

In this case we send MOVE_NONE that is different from MOVE_NULL.

Namely we send "bestmove (none)" to the GUI. Where is documented that in case of no legal move we should send "bestmove 0000" instead ?

Where isit specified that you are allowed to send "(none)"? This certainly is a violation of the protocol. The protocol defines only long-algebraicmoves or "0000", sending anything else is non-compliant.

As a null move means you are not moving, it seems to me you have to send a null move when you can't move.

Nowhere in UCI is documented the possibility for the engine to "express refusal" or similar behaviours. Could you please point me to that part in case I've missed ?

Nowhere it is documented that you cannot. It is documented that you can send null moves, though:

"A nullmove from the Engine to the GUI should be send as 0000."

So sending "bestmove 0000" is valid UCI. Now if that does not express refusal to play a move, what exactly would it express?

This is another undocumented feature. Where is written that a GUI can send a line with "0000" and what a correctly behaving engine is supposed to do upon receiving "0000" ?

You are right, the specs only define 0000 as valid engine to GUI move, not in the other direction. I would expect the engine to play a null move. But WinBoard+Polyglot never send null moves anyway.

[Tord Romstad]

i don't understand when/if an engine should send nullmove to the GUI

The most obvious case is when sending the current line(s) to the GUI with the "info currline ..." command, which Stockfish actually used to do. Of course we no longer do that, but I find that printing out lines with null moves is occasionally useful when debugging (but in that case, it of course doesn't matter whether they are printed as "0000" or something else, as long as it is recognizable as a null move).

[mcostalba]

So sending "bestmove 0000" is valid UCI. Now if that does not express refusal to play a move, what exactly would it express?

Unfortunately for you reading a protocol specification is not a guess work, or at least should not be. I agree that UCI protocol is not well defined in many places and that is written in a very loose way when compared to other transmission protocols common in computer science. But I also think that although the protocol is badly specified, it is even worst to try to "guess" the missing holes, as you are trying to do, and IMHO in a very handwaving way. So my take is that in those cases were the protocol is not well specified the behavior shall be assumed as undefined. In a properly written protocol we should _not_ have undefined behaviors, but UCI is far to be properly written.

[hgm]

I agree about the specs being poor, but I don't see how this ever could be a justification for sending it something that is obviously non-compliant, like "(none)".

In fact, if one does take the the specs seriously, in particular the part that says unexpected or unknownc commands should be ignored, it is a sure way to crash the GUI: after "bestmove (none)" the "(none)" part is ignored, and then the GUI will continue waiting for a move (forever...). It has simply not received a valid bestmove command, which the protocol specifies as mandatory!

[mcostalba]

it is a sure way to crash the GUI: after "bestmove (none)" the "(none)" part is ignored, and then the GUI will continue waiting for a move (forever...).

If your GUI does this it is seriously broken. I'd suggest to fix parsing logic. If the protocol wants "bestmove <move>" then the parser after detecting "bestmove" token should expect the next token to be the move, whatever it is, in our case "(none)", _after_ this syntactic step you may want to semantically validate the move and if you found that is illegal, not valid, etc, you should ignore it, but absolutely NOT wait for another one. This is totally ridiculous !!!

You should have clear the difference between syntactic and semantic rules when you write a parser.


BTW no GUI seems to crash when asks SF to search on a mate/stalemate position.

[hgm]

Somehow this seems a 180-degree turn compared to your previous remark that things not explicitly specified in the protocol should lead to undefined behavior. The protocol does not specify what will happen when you send somethingthat syntactically does not parse as a move, and ignoring something is something that is coveredby the term "undefined behavior", right? Is your engine as forthcoming as you want the GUI to be when it receives "0000" where it expects a move in the position/moves command?

But it seems you are prepared to fight to the utmost to keep your engine incompliant, so it is perhaps better you just do that. I don't care...

[zamar]

My understanding of the specs has always been that it's the responsibility of the GUI (or polyglot) to detect mates, 3-fold reps and 50-move draw. So the behaviour of the engine is undefined in such cases.

Where exactly in the specs does it say that?

Specs say that after each "go" command engine must send bestmove. If there are no legal moves in the position, engine cannot do this. So the behaviour is not defined by protocol.

This implies that any GUI shouldn't ask any UCI engine to search such a position.

[hgm]

The engine can send a null move. According to the specs this would be allowed: bestmove 0000 is allowed UCI syntax.

Extending your line of reasoning, engines should not be allowed to checkmate their opponents because it is not explicitly defined how the GUI should respond to that, and undefined situations should be avoided.

[Sven]

The engine can send a null move. According to the specs this would be allowed: bestmove 0000 is allowed UCI syntax.

Extending your line of reasoning, engines should not be allowed to checkmate their opponents because it is not explicitly defined how the GUI should respond to that, and undefined situations should be avoided.

In my opinion the UCI spec is very clear about "bestmove" in this case:

* if the engine or the GUI receives an unknown command or token it should just ignore it and try to parse the rest of the string in this line.

[...]

* bestmove <move1> [ ponder <move2> ]
the engine has stopped searching and found the move <move> best in this position.
[...]
this command must always be sent if the engine stops searching, also in pondering mode if there is a "stop" command, so for every "go" command a "bestmove" command is needed!

The engine must send a "bestmove" command for each "go" it receives, also for positions with no legal moves. So the engine has no choice here, except for the representation of the parameter for "bestmove". It is immediately obvious that the parameter must not be a valid move string, since there are no valid moves. Since the GUI shall ignore all tokens that it does not understand it is supposed to also ignore a token like "(none)". But this does not mean that it shall ignore the whole "bestmove (none)" command. Even though "bestmove 0000" would make everything perfectly clear for the GUI, also "bestmove (none)" must cause the GUI to understand that the engine has finished its search and that there is no move the engine wants to play.

So in my opinion the Stockfish solution is correct but needs getting used to.

Personally I would prefer a non-ambiguous spec but often this can only be achieved by being too restrictive. For games where not moving is a legal choice it would be essential to make a clear distinction between "I don't move since I have no legal choice left (i.e. game over)" and "I don't want to move (i.e., pass)". For chess and the UCI "bestmove" command this does not seem to be strictly required.

Sven

[Roger Brown]

Personally I would prefer a non-ambiguous spec but often this can only be achieved by being too restrictive. For games where not moving is a legal choice it would be essential to make a clear distinction between "I don't move since I have no legal choice left (i.e. game over)" and "I don't want to move (i.e., pass)". For chess and the UCI "bestmove" command this does not seem to be strictly required.

Sven

Hello Sven,

I hate demonstrating my total lack of competence but are you saying that by extension that UCI engines are not suited for analysis? I mean, they must consider what would happen if they did nothing and their opponent were to be allowed a free move.

Then they head off that possibility and so on. So if my opponent has a mate in one if I do nothing, clearly I must deal with that possibility before considering anything else as mate ends the game.

So why can't a null move be actually played in analysis? I pass is not legal in a game context but it is a vital analysis possibility.

Isn't it?

Please clear up my doubtlessly vast ignorance.

Later.