syzygy wrote: ↑Sat Jul 06, 2019 1:59 pmIt 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.
But UCI engines have no formal ways to complain. It seems to me they are actually more likely to crash when you send them unknown keywords.
In WinBoard/XBoard I would of course make this behavior subject to the engine saying 'feature delay=1' at startup. For UCI we could decide that engines implementing this convention must declare the check option UCI_NegativeIncrementMeanBronsteinTimeControlWithAbsoluteValueAsDelay with default value 'true'.
syzygy wrote: ↑Sat Jul 06, 2019 1:59 pmIt 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.
But UCI engines have no formal ways to complain. It seems to me they are actually more likely to crash when you send them unknown keywords.
UCI engines reply to the "uci" command with a list of the supported options. So one of these options should indicate that the engine supports delay TCs.
If the option starts with "UCI_", a GUI that does not know the option should ignore and not display it. So this also gives a way of ensuring compatibility with GUIs that are not aware of delay TCs.
You are correct that UCI does not have a way of complaining about unknown keywords, but at least UCI_ options seem to give a relatively clean way (intended or not) of extending the protocol.
For UCI we could decide that engines implementing this convention must declare the check option UCI_NegativeIncrementMeanBronsteinTimeControlWithAbsoluteValueAsDelay with default value 'true'.
So we mostly agree, except that I would rather propose UCI_DelayTC (or so) with a default value of "false". Setting it to true could enable wdelay and bdelay (or reinterpret winc and binc if a combination of delay and inc really makes no sense).
A delay is actually an increment, except that it is a limited increment rather than a fixed one. So I would keep using winc / binc and not add new keywords.
Gabor Szots wrote: ↑Sat Jul 06, 2019 4:29 pm
What is a delay?
Instead of adding time back to the clock as an increment would, the clock stops for the duration of the delay.
The main difference is that you can't gain time on the clock with a delay by making fast shuffling moves on purpose.
This delay feature works well in human tournaments. It is widely used in the North America, but less elsewhere.
The increment seems to serve engine games better, on the whole, imho.
Gabor Szots wrote: ↑Sat Jul 06, 2019 4:29 pm
What is a delay?
Instead of adding time back to the clock as an increment would, the clock stops for the duration of the delay.
The main difference is that you can't gain time on the clock with a delay by making fast shuffling moves on purpose.
This delay feature works well in human tournaments. It is widely used in the North America, but less elsewhere.
The increment seems to serve engine games better, on the whole, imho.
Has anyone played using an hourglass type of time control ?
Many digital chess clocks support hourglass format, but i've it's very uncommon it seems.
In "Hour Glass" options players start with the same amount of time on the clock (say one minute) but everytime one player's clock is counting down, the other player's clock is counting up.
Nordlandia wrote: ↑Sat Jul 06, 2019 7:44 pm
Is simple delay better than Bronstein delay`?
Has anyone played using an hourglass type of time control ?
Many digital chess clocks support hourglass format, but i've it's very uncommon it seems.
In "Hour Glass" options players start with the same amount of time on the clock (say one minute) but everytime one player's clock is counting down, the other player's clock is counting up.
I think that the only difference between Bronstein delay and simple (U.S.?) delay is whether the delayed seconds are displayed or not, no real difference. We used egg timers ("hour Glass") 55 years ago in high school when we didn't have chess clocks, but I don't see much merit to the idea now.
Nordlandia wrote: ↑Sat Jul 06, 2019 7:44 pm
Is simple delay better than Bronstein delay`?
Has anyone played using an hourglass type of time control ?
Many digital chess clocks support hourglass format, but i've it's very uncommon it seems.
In "Hour Glass" options players start with the same amount of time on the clock (say one minute) but everytime one player's clock is counting down, the other player's clock is counting up.
I think that the only difference between Bronstein delay and simple (U.S.?) delay is whether the delayed seconds are displayed or not, no real difference. We used egg timers ("hour Glass") 55 years ago in high school when we didn't have chess clocks, but I don't see much merit to the idea now.
yea, there's nothing worse than watching that sand slide to the bottom half .... talking about adding stress ...maybe that what we're told we are old now...
There is couple of youtube videos about how hourglass time format looks like. I made this video last year to showcase it. I managed to import SF and K into chessmaster 11 gui last year and let them play but it turns out that they don't understand the format. During about the same time i made the video i PM'ed the inventor of UCI protocol Stefan-Meyer Kahlen about this type of time format and he said it was on his to-do-list and he replied that hourglass will likely be available in next Shredder GUI. Now today well a year later i don't know if next version of Shredder is under development. UCI haven't been updated in years so maybe a maintenance update fits in with the hourglass format.
