UCI nullmove

[hgm]

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.

It should not ignore it, but it should keep waiting for a valid move token.

[bob]

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.

On a pure technical basis, it is problematic. For example, what do you do about hashing? Positions stored in a circumstance where a real move was played at the previous term are different than positions stored after the opponent passes. Repetitions? What about looking up positions on either side of the "pass"? What about using scores from after the pass to influence results prior to the pass? You probably have to toss the hash table out the window, at the least. And repetition detection? Just as messy.

So internally, it is an issue, not just getting it into the game score. Crafty accepts a "pass" (Tim Mann added that to xboard years ago and also added it to Crafty, so that a game could start off with black to move, and still the user could back up and go forward without crafty/xboard getting into a snit. But he didn't allow it in the middle of a game, I think that's something HGM has done.

[zamar]

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

Sorry, but null move is not legal in standard chess.

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.

According to my reasoning engine must be able to cope with any response from GUI, because GUI's behaviour is not defined in the checkmate case.

In similar fashion GUI _can_ ask engine to search checkmate position, but it must be able to cope with any response. (But of course this completely pointless and would be wise to avoid this)

[hgm]

[quote="zamar"]Sorry, but null move is not legal in standard chess.
[quote]

Moving when you are checkmated is illegal in standard chess. You don't notice any correspodence between that?

I still don't see the logic why a GUI must be prepared for _any_ response when it presents the engine with a checkmate position. What would be the reason for exempting the response to be valid UCI? Or a pertinent violation of it?

It seems that you are just making up your own requirements, which have absolutely nothing to do with UCI, and in fact are only designed for maximizing the chances that things willnot work in practice. Not a good idea.

[mcostalba]

I pass is not legal in a game context but it is a vital analysis possibility.

If a GUI wants to implement a "null move", i.e. asking the engine to move with opposite color, I think the proper way is to send the current position's FEN string to the engine with side to move reversed.

[mcostalba]

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.

Clearly you have not understood what I have written previously, and this is ok, I can live with that nor I tried to reply. But now you have just demonstrated of having also not understood what Joona has written and you even laugh at him !

I made up my mind it is a waste of time trying to discuss with you about protocols, and this is amazing given that, being a developer of x-board, you should know better about this topic.

[hgm]

What is amazing is that you let your engine do something completly unique, where other engines do something completely different, and then insist that this is preferable over every engine doing the same thing rooted in the protocol specs. Discussing about that is indeed a waste of time. Like discussing why the sky is green is a waste of time...

[mcostalba]

What is amazing is that you let your engine do something completly unique, where other engines do something completely different, and then insist that this is preferable over every engine doing the same thing rooted in the protocol specs. Discussing about that is indeed a waste of time. Like discussing why the sky is green is a waste of time...

Ok, let's do the last attempt to discuss on topic.

Please state clearly, without comments / opinions, what SF does differently from other engines and what should do.

As a hint for yourself please remember that a null move (coded as "0000") is _not_ MOVE_NONE, in particularity, if there are no legal moves it is not correct to send

"bestmove 0000"

it is incorrect as would be to send "bestmove a2a4" or anything else. A null move it means to give the possibility to the other color to move instead of you, it means to pass the move so it has _nothing_ to do with the following facts:

- Communicate to the GUI that there are no legal moves available

- Communicate to the GUI that we have crossed the 50 rule threshold

- Communicate to the GUI that we have done a 3-fold repetition

- Add here your special meaning motivated by the infamous (and deadly broken) "because I don't see what else could be" way of reasoning.

[Sven]

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

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.

At this point I was replying on a sub-thread where the topic was the correctness of certain parameters of the "bestmove" command, which is a required reply of the engine to the "go" command sent by the GUI. This is not related to analysis since the "bestmove" command is not a part of the engine's analysis output (which is sent via "info" lines), it is only the final result of a search (or analysis).

My point was that, since the null move (in the sense of "pass") is not a legal move and cannot be made by the engine as a move being part of the actual game, it does not make a difference for a standard chess UCI GUI whether the engine sends "bestmove 0000" or "bestmove (none)" or any other unknown parameter for "bestmove", in all cases it satisfies the protocol by replying to "go" with "bestmove" but indicates not to play any move.

The Stockfish interpretation is that even "bestmove 0000" were not correct in this case. I will reply on that part in a different post.

Sven

[Sven]

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.

It should not ignore it, but it should keep waiting for a valid move token.

I quoted the relevant part of the UCI spec above, read again. If the engine sends a valid command (here "bestmove") but an unknown parameter token (here "(none)" for instance), it should not ignore the whole command but only the unknown token. Ignoring the whole command would contradict to the sentence of the spec I quoted. So "bestmove (none)" can only mean that the engine has fulfilled its duty to reply to "go" but has not made a move (for which the reason is obvious).

Sven