Note that the DTM (which you report) is not relevant, and it is the DTC that counts. After the conversion, you are no longer in KRKR but in KRK, and there is no danger the latter will be adjudicated as draw. The longest DTC in KRKR is 3 (check - skewer - capture).
Are there KRKR positions where DTM<DTC but DTM>3?
I don't see how off the top of my head, but that may be lack of imagination on my part. In case of doubt, one could always use tablebase adjudication. I would consider this dangerous in general (engines might bungle the draw or win) but in these particular cases the danger of that is practically 0.
Evert wrote:Are there KRKR positions where DTM<DTC but DTM>3?
That is a logical impossibility if DTC.max = 3: DTM < 3 but DTM > 3.
XBoard has an EGT-based anti-time-wasting feature that should not distort engine capabilities: In positions that are bitbase draws, it can reduce the thinking time of selected engines by a user-specified factor. This way you can avoid that two engines using EGT go on forever trying to swindle each other out of a draw, with 0% chance of success. Deep searches in drawn positions are quite useless: you know there is nothing to find. You just want the engine to play by its evaluation.
Evert wrote:Are there KRKR positions where DTM<DTC but DTM>3?
That is a logical impossibility if DTC.max = 3: DTM < 3 but DTM > 3.
Oh. Right.
Never mind, moving on.
XBoard has an EGT-based anti-time-wasting feature that should not distort engine capabilities: In positions that are bitbase draws, it can reduce the thinking time of selected engines by a user-specified factor. This way you can avoid that two engines using EGT go on forever trying to swindle each other out of a draw, with 0% chance of success. Deep searches in drawn positions are quite useless: you know there is nothing to find. You just want the engine to play by its evaluation.
I'm not sure I see that. The position may be a draw, but that doesn't mean that it's a dead draw: it could still be that you need to defend accurately to keep the draw.
True, but you would only use the option on engines that you know to use EGT. These can never make a losing move in a drawn position, no matter how shallow their search, or how difficult it would be to salvage the draw. Engines that do not use EGT would still have to prove themselves.
hgm wrote:True, but you would only use the option on engines that you know to use EGT. These can never make a losing move in a drawn position, no matter how shallow their search, or how difficult it would be to salvage the draw. Engines that do not use EGT would still have to prove themselves.
Hmm... but then I'm not sure the option really does anything. Engines that use a tablebase would surely move immediately anyway? I suppose if they actually use a bitbase to decide whether a position is won or not they would still need a search to make progress, but if you're only keeping the draw there is no optimal path and search will not help you either...
Evert wrote:Engines that use a tablebase would surely move immediately anyway?
No, they don't, in a drawn position. At least not with syzygy. If they did, they would not distinguish drawn positions where the opponent would have to walk a thight rope to salvage the draw from those where it has to rely on a miraculous escape for itsef, and would quickly and happily turn the former into the latter. E.g. the famous example in KBPPKB with unlike Bishops where it sacs a Pawn on the first move, another one on the second, and its Bishop on the third, and then thinks that it has played perfectly. So you only move instantly when the position is won or lost, going for the fastes win or slowest loss. But in drawn positions you let the engine play the move that is best according to its heuristic search (which probably won't involve sacrificing Pawns and Bishops, walking its King to a corner, allowing the opponent King to walk to the center or step in front of your passers, etc.).
