| |
BGonline.org Forums
ZMF-II programming bug
Posted By: Chris Yep
Date: Friday, 4 August 2017, at 9:51 p.m.
I recently discovered a programming bug with ZMF-II clocks. As far as I can tell all (or at least most) ZMF-II clocks malfunction every time a player's time dips below one minute. The clock doesn't count down properly when the remaining time is less than one minute. Instead of counting down in increments of 0.1 seconds, as the clock approaches each integer second (XX.0) the clock first decreases by 1.1 seconds (e.g. from 59.1 to 58.0) and then increases by 0.9 seconds (e.g. from 58.0 to 58.9).
In other words, the clock will count "down"
..., 1:03, 1:02, 1:01, 1:00,
59.0, 59.9, 59.8, 59.7, 59.6, 59.5, 59.4, 59.3, 59.2, 59.1,
58.0, 58.9, 58.8, 58.7, 58.6, 58.5, 58.4, 58.3, 58.2, 58.1,
57.0, 57.9, 57.8, etc.
...
01.0, 01.9, 01.8, 01.7, 01.6, 01.5, 01.4, 01.3, 01.2, 01.1,
00.0, 00.9, 00.8, 00.7, 00.6, 00.5, 00.4, 00.3, 00.2, 00.1, followed by the clock officially "flagging." (See the discussion at the end of this post about when the clock flags.)I don't own a ZMF-II clock, but I like the look and feel of the clock. So, I'll probably happily play matches with this clock (if my opponent or tournament director supplies the clock) despite the bug. But in general I want other backgammon players to be aware of the bug.
Here's a more detailed description of the bug:
Essentially, with less than one minute remaining, every time the clock displays XX.0 seconds the actual time remaining is one second greater. When the clock first displays 59.0 it should really display 60.0 (with "60.0" defined to mean more than 59.9 seconds and less than or equal to 60.0 seconds, i.e. 59.90 < Time Remaining <= 60.00 seconds).
If, for example, a player stops the clock at 17 seconds, the clock will incorrectly display 16.0 seconds. When the clock then starts counting "down" again (for standard backgammon matches: the next time that the player fails to make his move within the delay period) it will first display 16.0 (instead of the correct 17.0) followed by 16.9, 16.8, etc.
I first noticed this bug while watching the Alan Grunwald vs. Kazuki Yokota World Championship match a few days ago. At the end of the second-to-last game Yokota's clock displayed 16.0 seconds. For the next several minutes he made every move within the 15-second delay period so his clock continued to display 16.0. However, when he finally overstepped the 15-second delay, to my surprise his clock jumped to 16.6 seconds at the end of the move!
Reviewing the match later in slow motion (in Twitch/YouTube one can view the video at 25% speed; I used an external viewer to slow down the video even further) I figured out what happened (see links below for the video):
At the 3:01:51 mark Yokota's clock read 22.5 seconds. He then took 20.5 seconds to make his move (15 seconds of delay plus 5.5 seconds of clock countdown). His clock should have finished at 17.0 seconds, but it incorrectly displayed 16.0 seconds at the end of his move. During these last 5.5 seconds the clock counted 22.5 (start), 22.4, 22.3, 22.2, 22.1, 21.0 (a decrease of 1.1 seconds), 21.9 (an increase of 0.9 seconds), 21.8, ..., 17.2, 17.1, 16.0 (a decrease of 1.1 seconds). For the next several minutes he made each of his moves within the 15-second delay period, so his clock remained at 16.0 seconds instead of the correct 17.0 seconds. Later, at the 3:07:20 mark he took 15.4 seconds to make a move. The clock then counted 16.0 (start), 16.9 (an increase of 0.9 seconds), 16.8, 16.7, 16.6.
To verify that it wasn't just a bug with the particular clock used in the Alan Grunwald vs. Kazuki Yokota match I looked at additional matches which used a ZMF-II clock where one or both players experienced time trouble (defined as less than one minute of time remaining). I found these matches in the large collection of matches published on USBGF's YouTube channel (USBGFbroadcast). I noticed this exact same bug in every single time trouble match that I looked at (6-8 more examples with no exceptions). The bug occurred on ZMF-II clocks with blue LEDs as well as on ZMF-II clocks with green LEDs. (The red LED ZMF-II clocks are much less popular so I didn't have time to look for any time trouble matches with red ZMF-II clocks.) My guess is that the bug afflicts every recent ZMF-II clock. My guess is that for most players the bug will usually not be noticeable. However, when the move finishes at XX.0 the displayed time will be off by one second, which could cause controversy later in the match.
Another example of a move finishing at XX.0 (this time with a ZMF-II green LED clock):
Ben Friesen vs. Brian Lonergan, Atlanta 2016 (see links below for the video):
At the 1:37:08 mark Brian Lonergan took 12.2 seconds to move (12-second delay). His clock should have counted down from 39.2 to 39.0 seconds, but instead the clock displayed 38.0 seconds at the end of his move. At the 1:39:26 mark he took 21.5 seconds to move. His clock counted 38.0 (start), 38.9, 38.8, ..., 38.2, 38.1, 37.0, 37.9, 37.8, ..., 29.5 seconds.
Finally, this begs the question: What happens as the clock approaches zero? Will the clock "flag" a second too early? I don't own the clock myself, but it appears that the answer is "no." I only found one match (YouTube, USBGFbroadcast channel) that used a ZMF-II clock where a player timed out, so my sample size is small (the player losing on time is a regular poster here). In this match the clock did NOT flag a second too early. The clock counted down: 01.3, 01.2, 01.1, 00.0, 00.9, 00.8, ..., 00.3, 00.2, 00.1, before finally flashing zeros (i.e. "flagging"). In other words, when the clock should have displayed 1.0 seconds it displayed 0.0 seconds. I don't know what would have happened if the player had stopped the clock during this tenth of a second interval. Presumably the clock would have displayed 00.0 (instead of the correct 01.0) without "flagging," which might have created controversy since the players would not have known about the clock bug. Presumably the next time the player overstepped the delay period his clock would have counted 00.00 (start), 00.9, 00.8, etc.
Overall, I didn't find any evidence of the clock shortchanging a player's time (or giving him extra time). The clock simply displays the wrong value at 60.0, 59.0, 58.0, ..., 2.0, and 1.0 seconds. Although I was able to see the "count down" bug at 100% speed (because I knew to look for it), in practice most players will only notice it when a move ends on one of these times (XX.0 seconds).
| |
BGonline.org Forums is maintained by Stick with WebBBS 5.12.