Regarding options ponder flag

[hgm]

So your thesis is that in case of a ponderhit the engine do not have the rights to know the correct clock time?

Indeed. This definitely is a design flaw in UCI. You have to send it the opponent's clock time with the go-ponder command, when it is not yet known. (Of course your own time was known then, as your clock is not running during ponder.)

A sensible design would have had the clock times on the 'ponderhit' command.

[Ras]

A sensible design would have had the clock times on the 'ponderhit' command.

Taking a look at WB engines: which engine does actually use this piece of information? Especially, does Kingslayer evaluate it? And for what purpose?

[Fulvio]

I read again the UCI protocol specification

But... the ponderhit behavior is obviously a bug: why nobody have fixed it?

[Fulvio]

which engine does actually use this piece of information?

I do not understand the logic of this statement. If it is useless why sending it if the pondered move was wrong?

[Ras]

If it is useless why sending it if the pondered move was wrong?

Because the go-command just always looks like that?

[Fulvio]

Because the go-command just always looks like that?

I keep missing your point: why the go-command always looks like that if it is useless?

[Ras]

I keep missing your point: why the go-command always looks like that if it is useless?

Because the GUI doesn't have to care which side it is sending the go-command to.

[Fulvio]

Because the GUI doesn't have to care which side it is sending the go-command to.

Man, I give up: can you imagine a GUI sending the same go-command to both sides? When the GUI will receive the bestmove will it pick a random clock to be updated?

I always forget that there are fanboys for everything: God send us the UCI protocol and it is blasphemy to think that a small mistake may be simply fixed.

[hgm]

Taking a look at WB engines: which engine does actually use this piece of information? Especially, does Kingslayer evaluate it? And for what purpose?

Joker used it. The point is that in sudden-death-type games (i.e. increment contributes negligibly) the optimal time allocation is to use a time close to what your opponent uses. Even if in your own judgement he uses twice as much time as is healthy, you should not stick to what you consider optimal yourself. Because it is very dangerous to be out-searched by such a factor, and by the time the opponent will get in time trouble, the game will be decided in his advantage with plenty of (now useless) time left on your own clock. So you better not think, say, less than 90% of what he thinks. (E.g. target time = 0.1*optimal time use + 0.9*average opponent time use).

In case the opponent thinks faster than you, it is also very dangerous to let the time he has left on his clock ever become a significant factor larger than yours. If he thinks just 10% faster, near the ed of a long game he could have, say 4 times as much time left as you. (E.g. i a 5+0 game, he has left 40 sec after 40 moves, and you only 10 sec.) You will be badly outsearched, and probably lose. You could have prevented that by having played just 10% faster.

[Ras]

can you imagine a GUI sending the same go-command to both sides?

In any actual implementation, you assemble the string token-wise.

to think that a small mistake may be simply fixed.

The issue with "fixes" and "enhancements" is that they create standard diversity, which is pretty much the opposite of a standard.