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.
delay vs increment
Moderators: hgm, Rebel, chrisw
-
- Posts: 5960
- Joined: Sun Jan 10, 2010 6:15 am
- Location: Maryland USA
delay vs increment
Komodo rules!
-
- Posts: 2283
- Joined: Sat Jun 02, 2012 2:13 am
Re: delay vs increment
No reason to change. I like delay better, but computer chess is a different beast.
-
- Posts: 4889
- Joined: Thu Mar 09, 2006 6:34 am
- Location: Pen Argyl, Pennsylvania
Re: delay vs increment
I would like to see it implemented with both engines and GUI's , not neccesarily for engine matches, but for humans to train against.
-
- Posts: 12541
- Joined: Wed Mar 08, 2006 8:57 pm
- Location: Redmond, WA USA
Re: delay vs increment
Why not make it an option?
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.
-
- Posts: 2283
- Joined: Sat Jun 02, 2012 2:13 am
Re: delay vs increment
Of course, you could, but I don't see it as a major breakthrough for engine vs engine matches.
-
- Posts: 5960
- Joined: Sun Jan 10, 2010 6:15 am
- Location: Maryland USA
Re: delay vs increment
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.
Komodo rules!
-
- Posts: 27809
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: delay vs increment
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.
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.
-
- Posts: 10309
- Joined: Thu Mar 09, 2006 12:37 am
- Location: Tel-Aviv Israel
Re: delay vs increment
I see legitimate use case for negative increments.hgm wrote: ↑Sat Jul 06, 2019 1:38 pm 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.
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.
-
- Posts: 5566
- Joined: Tue Feb 28, 2012 11:56 pm
Re: delay vs increment
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.
-
- Posts: 27809
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: delay vs increment
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.Uri Blass wrote: ↑Sat Jul 06, 2019 1:55 pmI 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.
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.