I keep missing your point: why the go-command always looks like that if it is useless?Ras wrote: Because the go-command just always looks like that?
Discussion of chess software programming and technical issues.
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?Ras wrote: Because the GUI doesn't have to care which side it is sending the go-command to.
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.
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).Ras wrote:Taking a look at WB engines: which engine does actually use this piece of information? Especially, does Kingslayer evaluate it? And for what purpose?
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.
In any actual implementation, you assemble the string token-wise.Fulvio wrote:can you imagine a GUI sending the same go-command to both sides?
The issue with "fixes" and "enhancements" is that they create standard diversity, which is pretty much the opposite of a standard.to think that a small mistake may be simply fixed.
Ras wrote:wtf man, W-T-FFulvio wrote: The issue with "fixes" and "enhancements" is that they create standard diversity, which is pretty much the opposite of a standard.
You add a:
option PonderWTF type check
and for engines that supports it you replace ponderhit with:
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.hgm wrote: the optimal time allocation is to use a time close to what your opponent uses.
Next question, this time allocation scheme doesn't sound too complicated - does Kingslayer use it?
Actually, you can just send the timing after ponderhit. UCI engines are supposed to ignore unknown additional things. From the UCI spec:Fulvio wrote:You add a:
Since UCI also allows arbitrary whitespaces anywhere, engines cannot just expect the ponderhit line to beif 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.
it may as well be
Code: Select all
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.
Code: Select all
" ponderhit \n"
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?Ras wrote: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.
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.
No, it doesn't. But KingSlayer is an extremely simple engine, just one step up from micro-Max.Next question, this time allocation scheme doesn't sound too complicated - does Kingslayer use it?
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.hgm wrote:He must have see a complication at large depth
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.