Could stopwatch errors change race results, and physics experiments?

[anorlunda]

Ay ay ay. Here's yet another worry to give you headaches.

https://aapt.scitation.org/doi/10.1119/10.0003919
One of the examples explored the properties of an algorithm, described in an IBM Knowledge Center document designed to convert a binary field representing the number of counts of a quartz oscillator to integers for digital display.2 In Ref. 1, it was demonstrated that the algorithm was vulnerable to rounding error resulting in an incorrect digital display. Investigation associated with this example forms the focus of this note.

The timing simulation results presented in Ref. 1 suggested that uncorrected rounding error in stopwatch timer displays could be impactful if used for precision timing, such as for race times or in experimental physics. Here, we present and analyse race times obtained from swimming competitions. The data give a clear demonstration of anomalous stopwatch timing patterns, which can only be explained by rounding error. It is also shown that such rounding error can result in a set of times being wrongly ordered. In the context of a sporting event, this could lead to the incorrect ranking of athletes and hence the incorrect awarding of race positions. As a spin-off of Ref. 1, this note may be of interest to educators, with the results providing a resource for discussion and the approach providing a template for additional student projects.

 

[jedishrfu]

I guess I'm confused about the rounding error. I realize there will be a rounding error but feel its unlikely to matter in these cases.

If rounding occurs in successive steps then the error might accumulate and be noticed but wouldn't the prudent programmer always go back to the quartz count and reconvert each time a new measurement is made ie they wouldn't add floating pt conversions from intermediate results causing the error to occur.

I had a related case of rounding error in trying to draw a piano keyboard to the horizontal length of a window. I got the number of pixels in the horizontal direction divided by the number of white key to display and got a floating pt number of pixels for a white key width.

After successive adds, I noticed the keyboard was still too small for the screen due to rounding and truncation errors as I converted between floating pt and integers for pixel location.

In a kind of java pseudo-code:

int white_key_pixels = (int)(window_horizontal_pixels / num_white_keys); // truncation occurs at initialization time

int white_key_x = 0;

for (int i = 0; i<num_white_keys; i++) {
  white_key_x = white_key_x + white_key_pixels; // truncation makes white_key_x less accurate each iteration
  draw_white_key(white_key_x, white_key_pixels);
}

- vs -

float white_key_pixels = 1.0f * (window_horizontal_pixels / num_white_keys);

for (int i = 0; i<num_white_keys; i++) {
  int white_key_x =  (int)(i * white_key_pixels); // truncation occurs at display time
  draw_white_key(white_key_x, white_key_pixels);
}

 

[pbuk]

I have only skimmed the article but it seems to me that the authors are stating "it is possible to design stopwatches that don't work very well". There does not appear to be any evidence that any commercially available stopwatch uses such a flawed algorithm, and certainly nothing to indicate that any timing system certified for use in competition is flawed.

Edit: oh, and another conclusion is that "the accuracy of results reported to a thousandth of a second on a manually operated stopwatch cannot be relied upon". Who knew?

 

[russ_watters]

There does not appear to be any evidence that any commercially available stopwatch uses such a flawed algorithm, and certainly nothing to indicate that any timing system certified for use in competition is flawed.

Seems like the obvious solution (which I would expect is in widespread use) is that there is only one "stopwatch". Then the finishing order triggers the time recording, not the other way around.

 

[pbuk]

Seems like the obvious solution (which I would expect is in widespread use) is that there is only one "stopwatch". Then the finishing order triggers the time recording, not the other way around.

For major running events a photgraphic system running at at least 100 (1,000 for international events) frames per second is specified by the IAAF. Not sure about cycling but I believe it is similar. Swimming relies on contact pads (which is the cause of the controversy around Michael Phelps' victory in the 100m butterfly in Beijing): cameras would be difficult.

However for lesser events with manual timing, separate stopwatches are used to record each competitors time (again see the IAAF rules for how this works), however times are recorded to a more realistic precision of 0.1s, normally with double redundancy (i.e. three timers per competitor).

So in either case the 'problem' posited by the authors of the paper simply does not arise. @anorlunda I hope that helps you avoid a headache; for my part that's the second time I've read an article in the 'American Journal of Physics' that would have been rejected by a conscientious high school student: I won't bother again.

 

[russ_watters]

For major running events a photgraphic system running at at least 100 (1,000 for international events) frames per second is specified by the IAAF. Not sure about cycling but I believe it is similar.

Do you know if it is automated, though? Either way, the one clock and finishing order dictating the time are satisfied by that, even if you need a person to read-off the results.

 

[pbuk]

Do you know if it is automated, though?

Yes the slit-camera that records an image along the finish line is automatic, but interpreting it is done by a human. The image below clearly shows the winner; the distance between the red lines represents an interval of 1/1000th of a second.

Image taken from this page which has more information and interesting images from finish line slit cameras.

Either way, the one clock and finishing order dictating the time are satisfied by that, even if you need a person to read-off the results.

Yes indeed.

 

[Tom.G]

For those of you that did NOT read the article, here are a few important sentences:

Race times from two consecutive swimming competitions involving a total of 647 stopwatch-timed swims were analysed.4
.
.
.
The results for the frequency of the final two displayed digits (the tenth and hundredth of a second) are presented in Fig. 1. Particular pairs of final digits should not be preferred to others. The results appear to be anomalous: There are three digit pairs, namely, 00, 50, and 75, which together account for more than one eighth of the results; conversely there are eight digit pairs with frequency zero.

(bold added)

 

[DaveE]

Would anyone use a stopwatch in "experimental physics"? I think we've all moved way past that technology.

 

[anorlunda]

I would describe the anomalies found in the article as software bugs. The words "roundoff errors" in the title may be misleading. Software bugs could occur in expensive laboratory instruments as well as consumer devices.

The thing that caught my eye, is the "stealth" nature of the symptoms. Any common sense acceptance test for a timer device would focus on accuracy,
stability, calibration, and durability. A bug that biased certain decimal digit combinations in the calculated results is not the kind of thing most tests would expose. That's why I call it "stealth" (my words, not the article's words.)

Oversimplification may make it more apparent. Suppose you have an analog instrument with numeric decimal digit output. Suppose that a bug prevented the sequential digits '42' from appearing in the output at any position. Would your acceptance tests reveal that bug?

 

[pbuk]

I would describe the anomalies found in the article as software bugs.

Really? I would put it down to false assumptions: if there is an excess of x.50, x.75 and x.00 recordings then clearly some of these times are recorded to 1/4 second, not 1/100.

Note that the article starts off talking about timing software but the data that is reported as 'anomalous' is collected from people in a swimming club listening for a start signal and clicking buttons on manual stopwatches of unknown precision, writing down their interpretation of the result displayed ("Times were recorded by a timekeeper in each lane, using personal and club stopwatches from a variety of manufacturers").

Suppose that a bug prevented the sequential digits '42' from appearing in the output at any position. Would your acceptance tests reveal that bug?

Possibly not, but I would expect that this would have been eliminated at an earlier stage of development. Every software engineer that merits that title knows about roundoff error and issues with binary to decimal conversions. I am not saying that mistakes are never made, but the assertion of the article that their data demonstrates that such errors are present in precision timing software 'in the wild' is incorrect and should not have passed review.