Polyglot question

[H.G.Muller]

The UCI protocol on the other hand is designed for a GUI with chess knowledge.

It is just a trade off.

I am not sure what exactly is traded. It seems you would lose awfully little to allow 'bestmove 0000' to be used as result claim (the obligatory score field telling you the nature of the claim, 'cp 0' = draw, 'mate 0' = checkmated, other negative scores = resign, positive score = illegal move /position claim). And this minute extension of the protocol (more a tightening up of the specs, really) would allow the use of UCI by GUIs devoid of any game-specific knowledge.

Likewise, it is not sure what you would lose by allowing a draw offer to accompany the go command, 'go draw movestogo 12 ...', allowing the engine to contemplate acceptance, or refuse it by making a move.

So it seems you trade all these "can't do"s for no compensation at all. This makes it more a design oversight / flaw than a trade off. In your interpretation of the protcol, engines would have to check moves for legality anyway, to know which they would have to ignore. I.e. sending them "position startpos moves d7d5 e2e4" would be a perfectly valid way of sending them the position after 1. e4...

I thought too that it was meant for cases in which the engine does not have a bestmove to return (like a mate solver that does not find a mate).
However it seems other GUI's do not recognize it.

That might be because they are a crappy, non-compliant bunch, of course... Invited to be so by unclear protocol specs.

I think the GUI is free to do what it wants. Just pondering on the position seems logical. But why would the engine not supply a ponder move?

No idea. They might have moved from an 'only-move' situation without search, perhaps? Fact is that BlunderUSI doesn't provide one in any position.

[Michel]

I am not sure what exactly is traded. It seems you would lose awfully little to allow 'bestmove 0000' to be used as result claim (the obligatory score field telling you the nature of the claim, 'cp 0' = draw, 'mate 0' = checkmated, other negative scores = resign, positive score = illegal move /position claim). And this minute extension of the protocol (more a tightening up of the specs, really) would allow the use of UCI by GUIs devoid of any game-specific knowledge.

Well the designers of the UCI protocol probably deemed relying on engine claims to be undesirable. After all the engine
may cheat so the GUI must check the claim anyway (for my FICS client this is not a problem since I can rely on FICS
to verify claims).

[H.G.Muller]

A GUI can serve many purposes. For engine-engine games it is indeed very desirable to have it act as an impartial referee. For human-engine games this is not so relevant: the human opponent usually does not need the GUI to tell him that the engine is cheating, and if the GUI would side with the engine against his own judgement, he would simply feel that both are cheating. So in human-engine games having the engine decide about the game rules / game result is very workable, and in fact very flexible, as it allows you to use the GUI for more variants than it was designed for.

Excluding that possibility for no other reason that the protocol cannot handle it is a waste. It is not the task of a protocol to limit what can be done. The protocol should merely allow engine and GUI to communicate to each other what they want done. If my telephone company would bud in my callse, to tell me "sorry sir, you cannot say that! You are using words that we have blacklisted!", they would not have me as a customer for long. Especially if they blacklisted words that are essential for expressing totally legitimite desires on my part...

It is hard to disguise that UCI was really designed only with a very limited purpose in mind, namely having one particular commercial engine communicate with one particular commercial GUI, and is not really suitable as a protocol for general use. It is just too much colored by what was deemed desirable in that particular, very limited application. "My engine does implement draw offers, so a Chess-Engine Communication Protocol does not need a provision for draw offers...". "My GUI does not set the number of search threads from the common engine-settings dialog, as it targets human-engine play rather than engine-engine play, so we don't need to standardize that option...".

[H.G.Muller]

One more question: what is proper UCI pocedure for pondering?

Currently I send 'go ponder' after the engine has given its move (and loading the relevant position), and then 'ponderhit' when the opponent plays the ponder move.

But I just realize that this way the engine is not informed about the times on the clock. Should I send times with the 'go ponder' command? The time on the engine's clock is already known at that time, but the time of the opponent will be running. It only becomes known when I send ponderhit, but I don't think I can send wtime or btime with ponderhit...

[Michel]

It seems like it.

Polyglot just sends a normal go command (with the current wtime and btime) and appends "ponder" to it.

This the relevant snippet (slightly edited)

Code: Select all

   if (colour_is_white(Uci->board->turn)) {
                         engine_send_queue(Engine,
                                           " wtime %.0f btime %.0f",
                                           XB->my_time*1000.0,XB->opp_time*1000.0);
                     } else {
                         engine_send_queue(Engine,
                                           " wtime %.0f btime %.0f",
                                           XB->opp_time*1000.0,XB->my_time*1000.0);
                     }

                     if (XB->inc != 0.0){
                         engine_send_queue(Engine,
                                           " winc %.0f binc %.0f",
                                           XB->inc*1000.0,XB->inc*1000.0);
                     }
                     if (XB->mps != 0) {

                         move_nb = XB->mps - (Uci->board->move_nb % XB->mps);
                         ASSERT(move_nb>=1&&move_nb<=XB->mps);

                         engine_send_queue(Engine," movestogo %d",move_nb);
                     }

  if (State->state == PONDER) engine_send_queue(Engine," ponder");


[H.G.Muller]

Tricky. WinBoard does send you times before you start thinking, but does not give any feedback to an engine when the latter moves. Polyglot keeps its own clock to know what to send?

What happens to UCI engines when you do not send them a wtime and btime with a go command? Are they supposed to derive the allowed thinking time from a previous wtime or btime command? Or is the result completely undefined? I guess to know the proper opponent time after a ponder hit, they have no choice but to doo this.

[Michel]

Polyglot keeps its own clock to know what to send?

Yes:-)

Code: Select all

                        // the engine is playing a move

                        // MEGA HACK: estimate remaining time because XBoard won't send it!

                        my_timer_stop(State->timer);

                        XB->my_time -= my_timer_elapsed_real(State->timer);
                        XB->my_time += XB->inc;
                        if (XB->mps != 0 && (game_move_nb(Game) + 1) % XB->mps == 0) XB->my_time += XB->base;

                        if (XB->my_time < 0.0) XB->my_time = 0.0;

Are they supposed to derive the allowed thinking time from a previous wtime or btime command

I don't think so (given that UCI is mostly stateless),