Regarding options ponder flag

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

[Fulvio]

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

wtf man, W-T-F

You add a:
option PonderWTF type check

and for engines that supports it you replace ponderhit with:
ponderhitWTF i_want_the_correct_clock_because_there_is_no_reason_not_to


done, fixed

[Ras]

the optimal time allocation is to use a time close to what your opponent uses.

This assumes that the opponent knows better which positions need what amount of time. It becomes interesting if both sides make this assumption, then we have a feedback loop.

Next question, this time allocation scheme doesn't sound too complicated - does Kingslayer use it?

[Ras]

You add a:

Actually, you can just send the timing after ponderhit. UCI engines are supposed to ignore unknown additional things. From the UCI spec:

if the engine or the GUI receives an unknown command or token it should just ignore it and try to parse the rest of the string in this line.

Since UCI also allows arbitrary whitespaces anywhere, engines cannot just expect the ponderhit line to be

Code: Select all

"ponderhit\n"

it may as well be

Code: Select all

" ponderhit \n"

Therefore, they have to check whether the line begins with "ponderhit", while removing possible whitespace before "ponderhit" of course. Engine that don't support additional information will just stop parsing at that point.

[hgm]

This assumes that the opponent knows better which positions need what amount of time. It becomes interesting if both sides make this assumption, then we have a feedback loop.

This is not done on a per-positition basis, but based on average time use. Nevertheless, it is suspect if the oppoent suddenly thinks very much longer than average. He must have see a complication at large depth that invalidated what you ca see at lower depth. So should you really stick to a lower depth in that case?

As to the feedback loop: this is the reason for a factor < 1, like the 0.9 in the example. You do't wat to fully copy the opponent, if he is using sub-optimal time. You want to profit from his 'mistake' by gaining a little time on him, which might build up to a decisive advantage later in the game, if he does it too often. But being too greedy in that respect might mean you acquire that decisive time advantage only after you are checkmated, so you must re-invest part of it to isure against that.

Next question, this time allocation scheme doesn't sound too complicated - does Kingslayer use it?

No, it doesn't. But KingSlayer is an extremely simple engine, just one step up from micro-Max.

[Ras]

He must have see a complication at large depth

Probably in the last iteration that would be normal at this depth, and this takes much more time because the PV is changing early on, maybe even at root. But so what? First, that can be anything because I can't know how the opponent made up his PV anyway, and second, whatever it is - it will be one ply closer to me when it's my turn then it was to him.

As for the feedback loop - agree, that makes sense. I guess choosing the feedback factor below 1.0 moves the pole of the system into the left half of the complex plane, a mark of stable feedback systems.

However, that's actually possible with UCI, too - subtract your pondering time from the opponent's time as told with the go ponder command, and there you go. Oh, games over network and network delay? Well either the network delay is neglectable compared to the move time, or the whole setup doesn't make much sense anyway.

Sure it would be nicer if the time data were sent along with ponderhit, too, especially because engines unaware of this simply would ignore it. No special feature negotiation necessary. The problem is that there are tons of GUIs around that don't amend. Therefore, any engine that wants to support a new way has to implement both the new and the old stuff, and the result isn't simpler, it's just more convoluted.