Polyglot1.4.30b

[H.G.Muller]

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).

It will not let you move before the engine stops searching, and it will not let you move after the engine stops searching. It will not let you move because you told it the engine is playing (say) white, and in the current position white is to move. It will only allow you to enter a move when the turn reverts back to black (by the engine doing a move), or when the user intervenes to tell the GUI that the engine should now play black. (Which is usually not what you want after a failing mate search.)

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?).

There are IMO perfectly valid reasons for communicating with my engine while it is searching. I already mentioned changing number of CPUs. (E.g. as operator in a tournament I start a game and notice my engine is onlyusing 1 CPU in stead of 8, because I forgot to alter some setting I used during testing. Why should I be forced to wait untilthe next move to enable the other threads.) This might be YOUR philosophy, and it is perfectly OK you have one, but you can simply implement that in your engine by making it deaf for any setoption command while it is thinking. Othe engine authors might have other philosophies, and the GUI should not make it impossible for them to do things according to their philosophy.

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).

Most GUIs don't work that way. You have to give them commands to tell them what you want. Does it have to accept illegal moves, like emptySquare x ownPawn, because you want to set up a position, do they have to accept only legal moves, and if so, must the computer automatically generates replies to them or not. There are a lot of GUI states. Intis particular case only the user can know what he want to do next. So the GUI should better sit and wait to be told.

[H.G.Muller]

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.

Indeed, I think this is best. Sending "resign" would make the GUI revert to Edit Game mode automatically. But most likely the user would not want to return to Edit Game mode anyway. More likely he would want to be in Edit Position mode, to change the position.

I have never used WB analysis mode, but when I just looked up the protocol specs I was baffled by the fact that it is not required for analyzing engines to respond to the "move now" command. It seems to me that it would be very common when you are analyzing that you actually want to follow the engine's PV. This whole matter of mate-solving is a form of analysis, and trying to do it in Machine White or Machine Black mode is just asking for trouble. From what I understood the only reason for doing the latter is to safe the user of making the move himself. Enabling "Move Now" in analysis mode would basically solve that.

I don't know if Polyglot implements "Move Now", (there is no feature defined for it in WB protocol), but if it does, would it work correctly during analysis? I can easily adapt WinBoard to also send the move-now command ('?') during analysis, when the user clicks it. (Currently this happens only in Machine White, Machine Black and Two Machines mode, although the menu item is not greyed out in analysis mode.) This seems not to violate protocol specs (which stipulate that an engine should simply ignore '?' commands that it does not implement).

[F. Bluemers]

There is no "move now" or equivalent in uci.
Implementing 'move now' seems just a matter of checking the last pv from the engine.

[F.Huber]

There is no "move now" or equivalent in uci.

And what's then the meaning of "stop"???

[F. Bluemers]

There is no "move now" or equivalent in uci.

And what's then the meaning of "stop"???

it tells the engine to stop analyzing.
Oh,and just before you get an idea :no, do not to start a new search:

* The engine will always be in forced mode which means it should never start calculating
or pondering without receiving a "go" command first.

[Michel]

7451.908 Engine->Adapter: info string No Mate in 4 found ! (00:00)
7451.908 Engine->Adapter: bestmove
parse_bestmove(): missing argument
7451.908 POLYGLOT *** QUIT ***
7451.908 Adapter->Engine: quit
7451.908 POLYGLOT Closing engine
7451.908 Adapter->Engine: EOF
7451.958 Engine->Adapter: EOF
7451.960 POLYGLOT Calling exit

You could have a look at my latest version. I did nothing to especially accomodate ChestUci but it is now more or less usable anyway. The illegal bestmove command
makes PG resign but the message "No mate found" is correctly shown in the engine output window (but not in the info text field on the top of the screen).

Formatting info output as thinking output has some limitations it seems. You can have only one info message per depth.

Without proper support from winboard there is not much more PG can do I think.

[H.G.Muller]

Formatting info output as thinking output has some limitations it seems. You can have only one info message per depth.

Without proper support from winboard there is not much more PG can do I think.

Wy is that? WinBoard can have as many lines of thinking output with the same depth as you want, not? It would display them all in the Engine-output window. What more support would you need?

[F.Huber]

There is no "move now" or equivalent in uci.

And what's then the meaning of "stop"???

it tells the engine to stop analyzing.

and to return the best found move!

Code: Select all

* stop
   stop calculating as soon as possible,
   don't forget the "bestmove" and possibly the "ponder" token
                when finishing the search


So what else is this "stop" than exactly what "Move now" means?
(The engine stops its current calculation and returns the best move found so far)
I'm really wondering how anyone could misunderstand those simple protocol specifications ...

Oh,and just before you get an idea :no, do not to start a new search:

* The engine will always be in forced mode which means it should never start calculating
or pondering without receiving a "go" command first.

What has this to do with "Move now" or "stop"?

[F. Bluemers]

Yes,from the engine point of view,stop is indeed equivalent to "move now"
I am more used to it as a means to stop a pondersearch or just stop a search (f.i. shreddergui)where the move is just disregarded.

[F.Huber]

Yes,from the engine point of view,stop is indeed equivalent to "move now"

Well, that's all I wanted to hear!

I am more used to it as a means to stop a pondersearch or just stop a search (f.i. shreddergui)where the move is just disregarded.

Whether the returned "bestmove" is accepted or disregarded that's in fact a thing of the GUI (or the user): the first I would call "move now", the second "abort".

[F. Bluemers]

Polyglot already handles the "?" command ("move now" from the menu)

[F.Huber]

Formatting info output as thinking output has some limitations it seems. You can have only one info message per depth.

Without proper support from winboard there is not much more PG can do I think.

Wy is that? WinBoard can have as many lines of thinking output with the same depth as you want, not? It would display them all in the Engine-output window. What more support would you need?

I've also tried it now with Michel's new PG, but he seems to be right: every new "info string ..." just replaces the previous one.
But from what I can see in the PG log, it seems to send "1 0 0 0" in front of the PV (with the info string) - I don't know if this would make any difference, but shouldn't this rather be "0 0 0 0" (as we discussed in some of our postings above)?

[H.G.Muller]

I suppose that in WB protocol "force" is the equivalent of an "abort" command. Although the specs are silent if reaction to the force command should be instantaneous, or that the engine would be allowed to finish thinking on the current move, the implementation is such that when an engine does produce a move after WB has switched it to force mode, WB sends an "undo" to recreate the situation as if the engine hadn't.

Tis procedure is triggered by the user switching to Edit Game (or Edit Position) mode when the engine is thinking.

The alternative offered to the user is click "Move Now". Then the engine should produce a move (preferably immediately, but it is acceptable to ignore the command and just finish your search), and the GUI will play this move.

I think the logical transation of both the WB "force" and "?" commands would be UCI "stop", where the first one would discard any bestmove (and if it didn't the GUI would correct this rebellion by an "undo"), and the second one would play it. If the engine is not able to produce a move immediately, it should just wait until it can, which is acceptable for a WB implementation of "Move Now". (And I guess a logical necessity in any case, also acknowledged by the UCI reqquirement that "stop" should evoke a "bestmove" reply.)

[Michel]

I've also tried it now with Michel's new PG, but he seems to be right: every new "info string ..." just replaces the previous one.
But from what I can see in the PG log, it seems to send "1 0 0 0" in front of the PV (with the info string) - shouldn't this rather be "0 0 0 0" (as we discussed in some of our postings above?

There is a silly bug in WB which makes WB clear the output window when a pv of depth <=1 is received.. The proper way to do this would of course be with a flag for a new search.

I have added a WbWorkArounds which sends the info lines with depth 2. This does solve the problem for ChestUCI but not in general since if the engine itself decides to send
a pv of depth 1 after an info line the info line is lost. And it is not unlikely that an engine wants to send some debug info before embarking on the actual search.

[H.G.Muller]

I've also tried it now with Michel's new PG, but he seems to be right: every new "info string ..." just replaces the previous one.
But from what I can see in the PG log, it seems to send "1 0 0 0" in front of the PV (with the info string) - shouldn't this rather be "0 0 0 0" (as we discussed in some of our postings above?

No, it should send the last depth, as any decrease of the depth would be considered by WB as the start of a new search, for which the Engine Output window would be cleared. I see that depth 0 an 1 could cause problems, though. The code currently seems to be:

Code: Select all

    /* Clear memo if needed */
    if( lastDepth[which] > depth || (lastDepth[which] == depth && depth <= 1) ) {
        clearMemo = TRUE;
    }


("depth" is the depth field of the incoming thinking-output line, "which" identifies the engine responsible for it.) So d=1 would indeed behave as you say, but higher depths wouldn't. I am not sure why the equal-depth case is treated differetly upto d=1. I could remove this, but I have no idea what the adverse effects (if any) would be if I did. (Perhaps some engines do a dummy d=1 search to perform an input move, which you want cleared before it starts thinking on its own move even if the thinking output it produces in any search is for d=1. I know uMax does this, but this code was written at the time when uMax did not exist yet.)

[F.Huber]

No, it should send the last depth, ...

But what IS the last depth, if the engine hasn't even started thinking?
ChestUCI already gives some infos (like "Search for mate in ...") BEFORE it starts the current calculation.

IMO it would indeed be better to have some unique state, so that WB knows it should just display this info message (and maybe a "0 0 0 0" would really be a good idea, because I don't think that any engine would send such values in a usual game).

[H.G.Muller]

There is a silly bug in WB which makes WB clear the output window when a pv of depth <=1 is received.. The proper way to do this would of course be with a flag for a new search.

This is a great idea! I guess Alessandro was just lazy when he used this silly kludge to get reasonably acceptable behavior of the Engine-Output display. (It is not so much a bug, as this code seems to be purposefuly put there.) But I am sure we can forgive him: there are many places in WinBoard where a search could be started, (it could be a ponder search, a normal one analysis) and you have to be intimately acquainted with the code to catch them all. And there are race conditions, where you would receive a thinking-output line (e.g. ponder output) after having sent the command to start a new search, so relying entirely on the flag would occasionally lead to a false high-depth line appearing as the first one of the new search. But this is of course preferable over losing true output, in particular info lines.

As a slightly improved kludge I can of course suppress the clearing of lines that did have node count 0. By resetting lastDepth to 0 after such a line with d=1 is received, in stead of setting it to d (=1). That is perhaps not ideal, but it is so simple that I could do it immediately.

You might be wasting your time trying to program work-arounds in Polyglot for bugs in WinBoard. They should, and will be fixed there. People with old, defective WinBoard versions should simply replace them, rather than having to bother with cumbersome work-arounds. That is the best way to progress.

[F.Huber]

I have added a WbWorkArounds which sends the info lines with depth 2. This does solve the problem for ChestUCI but not in general ...

Yes, it's in fact working now for ChestUCI with your newest 1.4.35!

But (despite of your already mentioned problems with other engines) this depth=2 doesn't look very nice, and now WB doesn't clear this analysis window even when I load and solve a completely new position.

So this "info string" problem should really be solved more generally (and of course in concordance with WB!), and my opinion is still, that depth=0 would be the most logical solution.
(and furthermore WB should in fact NOT display those 4 numerical values for info lines)

[F.Huber]

I've just discovered another BIG problem with Polyglot and/or Winboard:

Code: Select all

15199.769 GUI->Adapter: option DefenderMoves=1
15199.769 Adapter->Engine: setoption name DefenderMoves value 1


DefenderMove in ChestUCI is of type 'check' (i.e. a checkbox), and this type has a value of either "true" or "false", but NOT "1" or "0".
So of couse no UCI engine would ever understand these checkbox-values sent from WB/PG.

[H.G.Muller]

OK, try this WinBoard, then. It should not clear the display on receiving a d=1 line after a d=1 info line. (Untested.)

I've just discovered another BIG problem with Polyglot and/or Winboard:

Code: Select all

15199.769 GUI->Adapter: option DefenderMoves=1
15199.769 Adapter->Engine: setoption name DefenderMoves value 1


DefenderMove in ChestUCI is of type 'check' (i.e. a checkbox), and this type has a value of either "true" or "false", but NOT "1" or "0".
So of couse no UCI engine would ever understand these checkbox-values sent from WB/PG.

This is a Polyglot problem. In WB protocol the value of a check is 0 or 1. It is Polyglot's task to translate that to proper UCI. (Thanks for spotting it, BTW.)