delay vs increment

[lkaufman]

I just learned that the current super-tournament in Croatia is being run with 30" delay, rather than increment. I believe the recent super-tournament in Norway also used delay instead of increment. Apparently, delay is now standard for the whole series of grand tour events. Delay has been the norm for US tournaments for decades now, with a few exceptions, but it seems that the rest of the world has taken a liking to it.
I don't know the reasoning behind this change, or whether it will become the norm in all FIDE events. But it poses a problem for us in computer chess; if delay replaces increment, we should change our testing to delay to match. But I don't know how many of the GUIs even support delay, and I suppose none of the programmers have programmed delay. Maybe we should at least start to discuss this. I don't have a strong opinion as to which method is better, increment or delay. The quality of play will be higher with increment, especially for engines, but there is a good case to be made that players should not be rewarded for aimless play in superior positions to build up their time.

[carldaman]

No reason to change. I like delay better, but computer chess is a different beast.

[MikeB]

I would like to see it implemented with both engines and GUI's , not neccesarily for engine matches, but for humans to train against.

[Dann Corbit]

No reason to change. I like delay better, but computer chess is a different beast.

Why not make it an option?

[carldaman]

Of course, you could, but I don't see it as a major breakthrough for engine vs engine matches.

[lkaufman]

Of course, you could, but I don't see it as a major breakthrough for engine vs engine matches.

No one has suggested it is a "breakthru". If it becomes the dominant way of playing in human tournaments, then at least it should be supported by GUIs and engines, and testers could choose which way to test. One thing I can predict: if engine testing is done with delay rather than increment, that will favor MCTS engines over A/B engines, because MCTS is more likely to benefit from using all of a fixed amount of delay.

[hgm]

To have minimal impact on the various engine-communication protocols, we could adopt the convention that a negative increment -S means a delay of S. There is no legitimate use case for negative increments.

It would be quite easy to adapt WinBoard/XBoard to support this; instead of adding S to the clock after every move it would add min(S, timeUsedForMove).

Byoyomi TC is another thing most GUIs don't implement.

[Uri Blass]

To have minimal impact on the various engine-communication protocols, we could adopt the convention that a negative increment -S means a delay of S. There is no legitimate use case for negative increments.

It would be quite easy to adapt WinBoard/XBoard to support this; instead of adding S to the clock after every move it would add min(S, timeUsedForMove).

Byoyomi TC is another thing most GUIs don't implement.

I see legitimate use case for negative increments.

negative increment is simply reduction and you can play a game with time control of 1 hour per game minus 10 seconds per move that means that you start with 1 hour and you have less 10 seconds after every move.

Rules are clear and there may be cases when you are in lost position because of time inspite of the fact that you have a way to force mate
and intelligent engine should evaluate time on the clock as part of the evaluation function.

[syzygy]

To have minimal impact on the various engine-communication protocols, we could adopt the convention that a negative increment -S means a delay of S. There is no legitimate use case for negative increments.

It seems more important to make sure that the GUI can detect engines that don't understand delay TCs. Engines might accept negative increments (and crash or - worse - behave erratically) but are more likely to complain if an unknown command or option is given or set.

[hgm]

I see legitimate use case for negative increments.

negative increment is simply reduction and you can play a game with time control of 1 hour per game minus 10 seconds per move that means that you start with 1 hour and you have less 10 seconds after every move.

Rules are clear and there may be cases when you are in lost position because of time inspite of the fact that you have a way to force mate
and intelligent engine should evaluate time on the clock as part of the evaluation function.

I don't consider that a legitimate use case. It makes no sense at all to continue a game where one of the players is doomed like he is falling into a black hole. It would elevate to a standard playing on for no other purpose than running the opponent through the flag, which is considered so undesirable that the FIDE actually made rules against it in sudden-death games. Negative increment is worse than sudden-death.

One can conceive all kinds of silly time controls. Like making the player that has used the most time at move 60 lose. (Which is actually quite similar to negative increment.) That doesn't mean that anyone would be remotely interested in actually using those.