CECP "time" and "otim"

[hgm]

Which is the same state because you can just implement "infinite" as "many years".

That is a kludge, and formally wrong.

That's the wrong way around - debug should be enabled from the GUI, which only GUIs will do that support it in the first place. If the engine doesn't support it, the command will just be discarded.

That assumes you can just send anything to an engine without ill effects. The feature mechanism was designed to prevent exactly that.

It is not legal to send another 'go' without a new position-moves.

The protocol spec does not say this.

It also doesn't say the opposit. That is what 'undefined' means.

It's not undefined, and even if it were, it wouldn't actually require an additional state.

Why not? Without such a state the state diagram cannot represent thet 'go' must be preseded by 'position'. Even if it would be true that the game state after 'go' is defined, it would still be undefined before the first 'position' command is received. If you drop the requirement that the state diagram has to indicate which command is allowed when, I can collapse any state diagram to a single state that only transitions to itself on any command.

It makes scanning for repetitions easier because the scan happens within the same array even for moves before the root position, i.e. from the game history.

That is not completely true, because of the issue first repeat / second repeat. In the search you should not recognize a repeat of a position that only occurred once in the game history as a draw.

[Ras]

That is a kludge, and formally wrong.

I'd prefer to call it "clever implementation".

That assumes you can just send anything to an engine without ill effects.

The protocol should define a debug enable command in the first place, and also that the engine has to cope with commands that it doesn't implement. CECP has an engine error response for the latter, in particular for "unknown command", from which I conclude that CECP requires engines to cope, or else that error response wouldn't make sense.

It also doesn't say the opposit.

It does say that the position upon go has to be the one transmitted with the previous position command. It does not mandate that the position command has to be right before the go command. So there may be other commands in between, which also also includes a go command. Though I agree that it could have worded that more clearly.

Even if it would be true that the game state after 'go' is defined, it would still be undefined before the first 'position' command is received.

If there has been no go command at all, the engine is free to implement what the author wants. The easiest way is to initialise the engine to the start position because then you don't need special treatment for a missing position command. You can introduce a dedicated state for that, but the protocol doesn't mandate it.

In the search you should not recognize a repeat of a position that only occurred once in the game history as a draw.

I'm doing exactly that, but yeah, that would be an issue if the engine reaches a position, makes a move that doesn't win, and would need to reach exactly that position again, but then continue with a different move. But I also remember at which depth within that array my search even started so that I can score mate distances in the search tree. So I could discern between positions before and after root.

However, the underlying problem is that the engine has a winning position, but doesn't know how to win. Hoping that it would stumble over the right move by luck is unlikely to gain Elo, I think.

[hgm]

The protocol should define a debug enable command in the first place, and also that the engine has to cope with commands that it doesn't implement. CECP has an engine error response for the latter, in particular for "unknown command", from which I conclude that CECP requires engines to cope, or else that error response wouldn't make sense.

If you would define a protocol from scratch you would of course define a way to present arbitrary output, and no commands to enable it would be needed at all. But the whole feature business is about extendability of the protocol while preserving backward compatibility.

It does say that the position upon go has to be the one transmitted with the previous position command.

It says 'previous', not 'preceding' or 'latest'. 'Previous' only has meaning in relation to a thing of the same kind: this one and the previous one. As this is referenced w.r.t. the 'go' command, 'the same kind' here must mean command not position command. So in my interpretation this does specify a 'position' command always has to immediately precede a 'go' command. Otherwise it would not be the previous command.

[Ras]

It says 'previous', not 'preceding' or 'latest'. 'Previous' only has meaning in relation to a thing of the same kind: this one and the previous one.

It says "previous"? I don't find that word in the whole spec. The literal text is just:

start calculating on the current position set up with the "position" command.

Modifying the position after go would not be the position set up with the position command.

'the same kind' here

What "same kind"? I don't find that expression in the spec either. I'm referring to the one from April 2006, as offered on Stefan's website. Do you have a newer version available?

And in general, you can't put too much weight on the individual words. I mean, the whole spec has a pretty odd way of using "should" which usually means a strong recommendation, not a requirement, but half of the "should" actually express requirements - which would usually need "shall". That's even more strange because the other term that is used is "must" which does express a requirement. Sometimes, also "will" is (ab)used for that. The UCI spec is workable, but you have to read it with good will.

[mvanthoor]

Some of the posts above seem to assume that if the engine is searching and then stops, the position and board and game state ends up in such a state that sending another "go (infinite)" (UCI) command would not be useful.

This isn't the case in my engine.

To be able to search multi-threaded, each thread needs its own copy of the board. My engine already does this, even though it doesn't yet make any workers. (Iterative deepening and a/b-search now just run in the SearchControl thread.) As soon as the engine needs to search, it sends (for example) "SearchControl::GoInfinite" to the search thread. This thread requests a copy of the current board of its own, and then uses this to kick off the search. When there are multiple workers, the board will obviously not be copied to the search thread anymore, but to each worker.

Because of this the engine never uses its internal board for anything but making either the usermove or its own move.

If the search or analysis is aborted and no move is made, the board is exactly as it was before, so if you do "go infinite, stop, go infinite, stop", both searches will be exactly the same, and even after the second "stop", the board (or anything else) in the engine will not have been touched.