Polyglot1.4.30b

[H.G.Muller]

I don't really know much about UCI protocol. Is the bestmove command required? I would expect the engine only would sent that command if it wants the GUI to do that move. If there is no move you want it to do, jut not send it.

In WB protocol there is the "move" command to make the GUI move on to the next position. If you don't want to go on to the next position, you simply should not send it. If you want to notify the user that the engine has stopped thinking, you could send thinking output to that effect. E.g. put "No mate found, stoped searching" in the PV field, and it would appear as a message above the board.

I guess logically searching for mates is a special form of analysis mode. You set up a position, and click "Analysis". The engine starts thinking and at some point the solution will appear. But the engine will not make the move in analysis mode. In normal analysis you would continue to increase the depth forever. But also there, when a mate is found, most engines will stop deepening and will revert to the idle state after nnouncing the PV that led to the mate in their thinking output.

If you want to evoke that behavior even without a mate being found at a certain depth, you should simply limit the depth with the WinBoard sd N command and set the engine to analysis. It then stops after the two-ply search has been completed, either with or ithout a mate score.

[F.Huber]

I don't really know much about UCI protocol. Is the bestmove command required? I would expect the engine only would sent that command if it wants the GUI to do that move. If there is no move you want it to do, jut not send it.

No, unfortunately that doesn't work!
As long as the GUI doesn't get any "bestmove ..." command, it thinks that the engine is still thinking (and that means you can't do anything in the GUI unless it has received such a bestmove).

For matesolving it would really be the best (and simpliest), if Polyglot and/or Winboard would accept an empty "bestmove " and just return to the state before, i.e. waiting for the next user action (e.g. changing any option or modifying the position, and start the search again).

BTW, is there any way in the new Winboard 4.4.1 to display any engine infos (I mean the text infos, that UCI engines are sending with "info string ...")?
Without that, lots of useful (or even necessary) informations are lost (for ChestUCI e.g. its current search status, what it finally has found, etc...).
Maybe this could be displayed in extra windows (like the engine analysis), or (even better) just together with the engine analysis in the already existing output windows (as Arena does it).

[F. Bluemers]

I don't really know much about UCI protocol. Is the bestmove command required? I would expect the engine only would sent that command if it wants the GUI to do that move. If there is no move you want it to do, jut not send it.

No, unfortunately that doesn't work!
As long as the GUI doesn't get any "bestmove ..." command, it thinks that the engine is still thinking (and that means you can't do anything in the GUI unless it has received such a bestmove).

For matesolving it would really be the best (and simpliest), if Polyglot and/or Winboard would accept an empty "bestmove " and just return to the state before, i.e. waiting for the next user action (e.g. changing any option or modifying the position, and start the search again).

BTW, is there any way in the new Winboard 4.4.1 to display any engine infos (I mean the text infos, that UCI engines are sending with "info string ...")?
Without that, lots of useful (or even necessary) informations are lost (for ChestUCI e.g. its current search status, what it finally has found, etc...).
Maybe this could be displayed in extra windows (like the engine analysis), or (even better) just together with the engine analysis in the already existing output windows (as Arena does it).

Polyglot could relay info string stuff with a trick,the info would be sended dressed up as thinking output.

[Michel]

Polyglot could relay info string stuff with a trick,the info would be sended dressed up as thinking output.

Or as debug output (prefixed with #).

Wb currently doesn't do much with debug output I think. It could show it in a separate window it it wanted to.

[F.Huber]

Polyglot could relay info string stuff with a trick,the info would be sended dressed up as thinking output.

Yes, that would be the best and most logical solution, and it wouldn't require any changes in Winboard. (I hope WB doesn't need a special format for these thinking lines?)
Arena does it exactly this way, in the Fritz-GUI you have to open an extra 'Engine output' window for this, but that's not very comfortable.

[H.G.Muller]

The PV field in the WB thinking output is free format. You could write anything you want there, and WinBoard will faithfully display it in the message field and engine output window. Any line starting with 4 numbers is considered thinking output.

A bit of care is required in supplying dummy numbers: if the first number, interpreted as depth, is lower than the previou one the engine-output window will be cleared before the line is displayed. So to display the lines amongest the normal PV lines, you would have to keep repeating the last depth that was sent.

[F. Bluemers]

Polyglot could relay info string stuff with a trick,the info would be sended dressed up as thinking output.

Yes, that would be the best and most logical solution, and it wouldn't require any changes in Winboard. (I hope WB doesn't need a special format for these thinking lines?)
Arena does it exactly this way, in the Fritz-GUI you have to open an extra 'Engine output' window for this, but that's not very comfortable.

polyglot would have to prefix the info with (faked if neccesary) "ply score time nodes" info.
the pv part is format free

[F.Huber]

polyglot would have to prefix the info with (faked if neccesary) "ply score time nodes" info.
the pv part is format free

Maybe it would be a good idea to make a small modification in Winboard especially for this case:
If Polyglot sends a 0 (or -1) as first (ply) number (because it got a "info string ..." from the engine), Winboard should completely omit those 4 numbers in the engine output window and start displaying the text string from the left border of the line. I don't know if this is possible (maybe all lines MUST have these 4 numbers at the beginning because of formatting reasons?), but this would definitely look much better.

[H.G.Muller]

It would not be a problem (the engine output is a text edit, and arbitrary lines are inserted in it at the top). But I strongly doubt that it would look better. I imagine that it would in fact look very ugly to interrupt the numeric columns with arbitrary text in an irregular way. Much better to align everything with the same left margin as the PV field. I'd rather simply suppress score/time/nodes when they are all zero. Then even in older WB versions it would not look very bad (just a few inconspicuous zeros). Imagine what it would do sending d=-1 to an interface that doesn't know this convention and implements the depth as unsigned...

No, unfortunately that doesn't work!
As long as the GUI doesn't get any "bestmove ..." command, it thinks that the engine is still thinking (and that means you can't do anything in the GUI unless it has received such a bestmove).

For matesolving it would really be the best (and simpliest), if Polyglot and/or Winboard would accept an empty "bestmove " and just return to the state before, i.e. waiting for the next user action (e.g. changing any option or modifying the position, and start the search again).

What harm does it do if it supposes the engine is thinking? Surely you can do things when the engine is thinking? E.g. press "move now", enter a pre-move. In analysis mode you can even simply enter moves when the engine is searching; the search is then aborted, and analysis of the new position starts. UCI engines can interrupt their search, not (e.g. in case of a ponder miss).

I don't see any problem. All this is fully implemented in WB protocol. No changes are needed at all. You should not send a move, though. I am not sure what would happen then. Likely it would be ignored, but you cannot be sure about that, as it is a breach of protocol.

[F.Huber]

What harm does it do if it supposes the engine is thinking? Surely you can do things when the engine is thinking? E.g. press "move now", enter a pre-move. In analysis mode you can even simply enter moves when the engine is searching; the search is then aborted, and analysis of the new position starts. UCI engines can interrupt their search, not (e.g. in case of a ponder miss).

I don't see any problem. All this is fully implemented in WB protocol. No changes are needed at all. You should not send a move, though. I am not sure what would happen then. Likely it would be ignored, but you cannot be sure about that, as it is a breach of protocol.

Well, what you say is absoultely ok for analysis mode, but not for the usual game mode. I've just tried it again in Arena, and when I manually make a move on the board while ChestUCI is thinking (in normal play mode), Arena doesn't send any "stop" command to the engine but just the new position.
And that's something I don't have implemented in ChestUCI of course, because it makes no sense IMO - ChestUCI searches for a mate until
a) it has found one,
or b) it has reached the adjusted search depth,
or c) it gets a "stop" command from the GUI,
but certainly NOT when receiving just a new "position" command.

And for case b) it's more than logical for me, that the engine should 'report' this situation to the GUI in an appropriate way - and IMO the best way is a simple "bestmove " (because there's no special command for that in the UCI protocol).

[H.G.Muller]

But you should not be in normal game mode, right? You are solving a mate-in-N problem, not playing a normal game. If you were playing a game you would indeed have to produce a move, and make the GUI play it, and the user would want to go on from there.

You don't want all that. I am not sure what exactly you want when Chest finds the solution, but apparently you do not want Chest to alter the position by making a move. So apparently the user is now supposed to alter the position. If so, why shouldn't this new position be sent to Chest? What good could altering the position ever do the user, if the new position was not sent to Chest???

[Teemu Pudas]

What harm does it do if it supposes the engine is thinking? In analysis mode you can even simply enter moves when the engine is searching; the search is then aborted, and analysis of the new position starts.

UCI requires a bestmove after every search. The Shredder GUI will kill and restart an engine that doesn't send it after being told to stop (and the GUI is unresponsive while doing this).

Arena doesn't send any "stop" command to the engine but just the new position.

That's... technically standard-compliant. But still a very, very ugly special case.

[F.Huber]

But you should not be in normal game mode, right? You are solving a mate-in-N problem, not playing a normal game. If you were playing a game you would indeed have to produce a move, and make the GUI play it, and the user would want to go on from there.

You don't want all that. I am not sure what exactly you want when Chest finds the solution, but apparently you do not want Chest to alter the position by making a move. So apparently the user is now supposed to alter the position. If so, why shouldn't this new position be sent to Chest? What good could altering the position ever do the user, if the new position was not sent to Chest???

Well, I see you're not very familar with ChestUCI, and certainly don't have read its (quite long) description.

Yes, I definitely do want the GUI to make the move that ChestUCI has found - at least in normal play mode!
The reason is simple: by pressing the 'Move' button in Arena repeatedly I can go through the whole solution without entering all those moves manually. And I also could make a different move myself to see, how the solution would look after this non-intended defending move (ChestUCI would just look into its solution tree or start a new search).

And when I really do NOT want that the found move is executed, well then I CAN use the 'Analyze' button in Arena - so I have both methods available.

[H.G.Muller]

Indeed I never used ChestUCI before I downloaded it yesterday, and my only interest in it was that it features push-button options which have an immediate visible effect. I never actually had it search... So I did not bother to read its description.

But you confuse me more and more. How could the GUI possibly perform the best move if you don't send it???

It seems to me that formally a search is not over when you want the GUI not perform the move yet. Wait for the user to push the "Move" button, and send the bestmove then, so the GUI can perform it. That the engine is not actually using any CPU time in the later parts of the search, should be of no consequence, from a protocol perspective. From the PV line the user should always be able to conclude if the engine is done thinking, and has found a solution or not.

[F.Huber]

Indeed I never used ChestUCI before I downloaded it yesterday

Shame over you!

But you confuse me more and more. How could the GUI possibly perform the best move if you don't send it???

Hmmm? Of course I do send the bestmove - in all 3 cases that I have mentioned above (and in both modes, normal play and analysis mode)!
And the problem only arises when ChestUCI has NOT found any solution, i.e. it can NOT send back any move to the GUI but just a simple "bestmove " instead, so the GUI knows that the search is definitely finished (even if it was not successful).

[H.G.Muller]

OK, sorry I am a bit slow, but now I start to understand what we are talking about. But why would the GUI need to know the search is over? Is there any spontaneous action that you want to trigger in the GUI? I would say it is the user that has to decide what is going to happen next. I guess the failure to find a solution is actually proof such a solution does not exist. Otherwise there wouldn't be any excuse for ending the search. So what would you expect a user to do in this case other than load a new position?

[F.Huber]

But why would the GUI need to know the search is over? Is there any spontaneous action that you want to trigger in the GUI?

Of course the GUI should know what's going on, i.e. whether the engine is still thinking or not!
I'd rather state exactly the opposite: you (the user) shouldn't even be allowed to do such strange things like changing the position (or any engine options, or whatever else) while the engine is currently thinking - that's just unlogical (and dangerous).

I would say it is the user that has to decide what is going to happen next.

Exactly - but when the engine is thinking and the user wants to do something completely different, then it's more than reasonable to stop the engine first before taking such actions.

I guess the failure to find a solution is actually proof such a solution does not exist. Otherwise there wouldn't be any excuse for ending the search.

But HOW should the GUI know that the matesearch has failed, if the engine doesn't report this situation back to the GUI??? (and that's exactly the reason for this empty "bestmove ").

So what would you expect a user to do in this case other than load a new position?

Well, there are many possibilities: you could change the search depth, modify any engine options etc. ...

[H.G.Muller]

Of course the GUI should know what's going on, i.e. whether the engine is still thinking or not!
I'd rather state exactly the opposite: you (the user) shouldn't even be allowed to do such strange things like changing the position (or any engine options, or whatever else) while the engine is currently thinking - that's just unlogical (and dangerous).

I would sy that is upto the engine. If an author wants to implement options that can be meaningfully changed during a search, (e.g. change number of search threads), it hould have the possibility to do that. The GUI should not block that. If the engine feels it is not ready to receive and process options, it can just buffer the input until it is ready.

The GUI will of course not let you move (unless it implements pre-move). But that is independent from the search still going on or not. It is simply because it is not your turn. It will still not be your turn when the search has ended, so that really makes no difference.

Exactly - but when the engine is thinking and the user wants to do something completely different, then it's more than reasonable to stop the engine first before taking such actions.

I would say the engine is formally thinking until the user stops it, by taking some action. (E.g. in WB you would switch back to Edit Game mode when you want the engine to stop thinking.) That would be true even when the engine had actually given up and was idling. More usual would be that you go to Edit Position (or equivalently, paste in a new FEN). If you would want the engine to retry with other settings, you could simply call up the Engine Settings Dialog, push "Stop" and "Clear Hash", and change the settings, and push "start" again. The GUI would't have to know anything about that.

But HOW should the GUI know that the matesearch has failed, if the engine doesn't report this situation back to the GUI??? (and that's exactly the reason for this empty "bestmove ").

This is the key point that I don't understand. WHY should it know? What exactly do you want it to do? I still odn't see any reason for the GUI to behave differently after it knows this. It should still "sit and wait". So it seems useless information.

[F.Huber]

This is the key point that I don't understand. WHY should it know? What exactly do you want it to do? I still odn't see any reason for the GUI to behave differently after it knows this. It should still "sit and wait". So it seems useless information.

Well, you've already answered this question yourself, at least partially: "The GUI will of course not let you move."
Exactly! And there might be other actions which the GUI shouldn't let the user do while the engine is thinking (because it could influence the search in an unexpected way).

But that is independent from the search still going on or not. It is simply because it is not your turn. It will still not be your turn when the search has ended, so that really makes no difference.

Sorry, but I don't understand this - we seem to have 2 completely different philosophies about the meaning of the GUI (and the communication between GUI and engine).

IMO there are 2 different situations in principle (despite of pondering, which is of no interest for matesearching):
Either the engine is thinking (because you have told it to do so with any "go" or "move" command), then it's the engine's turn - and in this case you shouldn't change ANYthing concerning the current game or position (or would you e.g. play around with the pieces while your opponent is thinking in a human game?).
Or the engine is NOT thinking (because it has finished its search, or you have stopped it), then it's YOUR turn (of course only after the GUI has executed the move if the engine has found one) - and NOW you can do whatever you want, either make a move by yourself, load a new position, change any options or even tell the engine that it should start thinking again (for your side).
And so I think one of the fundamental things the GUI has to know is at least the 'state' of the game, i.e. who's turn it is currently.

But I doubt that we will get any concordance about this, so I'll stop here to further discuss this fundamental problem - it's just too strenuous to explain and write so much in an other language ...

[Michel]

All said and done, not returning a bestmove might work for WB. You would have to return manually to Edit Game (force mode) if the engine does not find a mate. To relaunch
a search you would select "machine white" or "machine black" depending on the color.

An alternative is to use Fonzy's resign feature. This is not a protocol violation but a protocol extension in the way the UCI protocol was meant to be extendable.
Resign is implemented in my PG version as well as Fonzy's (I forked PG after he implemented it). It will have no effect on other GUI's since they have not implemented this feature.

Finally Fonzy's latest version and my upcoming version have made it so that PG will resign automatically if an illegal bestmove is received. But of course it does so while complaining loudly