UCI: What is the standard when there is no ponderhit?

[OliverBr]

Hello,

Let's asume the UCI-Sends the following:

Code: Select all

position startpos moves c2c4 g8f6 d2d4 e7e6 g2g3 d7d5
go ponder wtime 9210 btime 32639

So the engine starts pondering on that position until it gets, when the opponent actually played the expected move, it sends:

Code: Select all

ponderhit

(which is actually better than the xboard protocol, which sends a move which much be parsed... during search and the engine must decide if it's a ponderhit)
_______
But: If it doesn't play the expected move, I could not find a definite specification what happens next.
E.g. the lichess.org interface then sends:

Code: Select all

stop
position startpos moves c2c4 g8f6 d2d4 e7e6 g2g3 >a different move>
go wtime....

which is great, because "stop" just stops the (ponder)search and is not needed anymore.
But can there be interfaces, that don't send "stop", that just start with "position..."?
In this case it makes it complex to handle the situation.

Thank you for helping out

[Steve Maughan]

If there isn't a ponder hit, it is the GUI's responsibility to stop the search (with a 'stop' command) and have the engine start searching from the new move (with a 'position' and 'go' command). The example you gave from LiChess.org is a good one — the GUI has handled this correctly. This makes chess engine programming a little easier.

— Steve

[OliverBr]

If there isn't a ponder hit, it is the GUI's responsibility to stop the search (with a 'stop' command) and have the engine start searching from the new move (with a 'position' and 'go' command). The example you gave from LiChess.org is a good one — the GUI has handled this correctly.

So, a "stop" can be expected. This is great. Thank you.

This makes chess engine programming a little easier.

A lot. Because without stop, there is a command coming in during (ponder)search and it must be "saved" in order to be processed outside the search...

_________
I have another questions about UCI "ponder". It's explicitly said that after "go ponder..." the engine must not leave search until told so..
But some positions reach the final depth easily within short time.
What exactly should the engine do now? Just doing an empty loop until "stop" or "ponderhit" arrrives?
What is the best practice here?
Can other commands arrive theoretically like e.g."quit"?

[Steve Maughan]

You've identified the main weakness of the UCI protocol. Yes, you need to spin idlily until you get the "stop" command — same for an infinite search. Here's the code in Juggernaut that handles it:

Code: Select all

  while ((SearchState = ssPondering) or (TimeControl.SearchType = stInfinity)) and (fLocalGeneration = TThreadPool(FPool).Generatation) and not fAbortSearch do
    NanoSleep();

A "quit" command will never come while a search is in progress i.e. before a "stop".

Steve

[OliverBr]

You've identified the main weakness of the UCI protocol.

One interesting feature is is the stateless concept, which helps the engine developer a lot. No more undos or parsing moves while pondering etc...

But the reality is: Hardly any engine is really stateless. Most keep their hash-tables filled between the moves. This means, you can get different results depending on what happened before. This contradicts the concept a little.
Strictly following protocol a engine would had to either clear the TT or build it up identically for a position to calculate.

Other consequence is that it is not easy to play an uci engine in terminal/console :/ Anyway, who plays without a GUI nowadays?

[Aleks Peshkov]

To fight against stateless UCI I have to save previous position string and compare with latest and use difference to decide whether we still play the same game or something different.

The simple extension to UCI will not spoil holy grail statelessness: 'position fen|startpos' are optional, if they are not given it means moves are given from previous position command state. Any engine have to save 'position' till next 'go' anyway and no reason to forget it during search.

[OliverBr]

The simple extension to UCI will not spoil holy grail statelessness: 'position fen|startpos' are optional, if they are not given it means moves are given from previous position command state. Any engine have to save 'position' till next 'go' anyway and no reason to forget it during search.

Oh, this is not what I read in the specification or seen anywhere, thus is not implemented in OliThink this way.
For now it is implement as such: To move "e7e5", the engine must receive "position startpos moves e2e4 e7e5".
"moves..." alone won't work.

But it is an interesting idea, albeit completely abandoning the stateless concept. I am curios which engines support this?

[Steve Maughan]

...I am curios which engines support this?

The answer is "none". And a more important question is, which GUIs support this — and the answer is also "none". The volume of traffic might seem like a weakness of the UCI specification, but in reality it isn't a problem (taking up a tiny fraction of resources).

— Steve