Oops, I was wrong about vision: it uses a double storing seconds.<div>I've been using uint64 on the client side and in log files (to allow exact comparisons), which is why I thought it was also in the vision detection message.<div>
<div><br></div><div><div class="gmail_quote">On Fri, Nov 9, 2012 at 3:18 PM, Christopher Head <span dir="ltr"><<a href="mailto:chead@chead.ca" target="_blank">chead@chead.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Well, technically the OS gives it as nanoseconds. I didn’t want to go<br>
with uint64 nanoseconds because it would only be a few bits away from a<br>
32-bit time_t which suffers from the 2038 bug (admittedly it would be a<br>
few orders of binary magnitude, but still). Then Joydeep implied he<br>
thought milliseconds were not as fine as they could be. I like the<br>
tradeoff of using microseconds though! Joydeep, what do you think? (or<br>
anyone else)<br>
<br>
Chris<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, 9 Nov 2012 13:55:44 -0800<br>
Ben Johnson <<a href="mailto:circuitben@gmail.com">circuitben@gmail.com</a>> wrote:<br>
<br>
> I am in favor of using integers for time.<br>
> If we use floating-point seconds, we have a potential rounding error<br>
> because we need so much dynamic range. Because 1e-6 can't be<br>
> represented exactly in a float64, adding one microsecond to a time<br>
> produces an incorrect result (see the demonstration code below).<br>
><br>
> If we use floating-point microseconds, that is no better than integer<br>
> microseconds, but with a less elegant implementation. Vision uses<br>
> integer microseconds in a uint64, and timing matters much more for<br>
> vision than for referee messages.<br>
><br>
> A double doesn't give significantly better resolution than one<br>
> microsecond (less than two bits), and since it can't actually<br>
> represent one microsecond exactly, I would argue that it's worse. It<br>
> introduces rounding error without any advantage.<br>
> Referee messages except for time remaining are inherently<br>
> high-latency, because they pass through two humans before they reach<br>
> the computer. Extremely high precision is not necessary.<br>
> If for some reason we actually need better resolution, I would suggest<br>
> adding more bits as another field. The purpose of floating-point<br>
> formats is to provide a variable exponent, which we don't need here.<br>
><br>
> It's easy to convert to a double on the receiving side, but it's hard<br>
> to fix rounding errors after the fact. I would rather see the time<br>
> exactly as the OS originally gave it.<br>
><br>
> Rounding demonstration:<br>
> #include <stdio.h><br>
> #include <sys/time.h><br>
><br>
> int main()<br>
> {<br>
> struct timeval tv;<br>
> gettimeofday(&tv, 0);<br>
><br>
> double t0 = tv.tv_sec + tv.tv_usec * 1.0e-6;<br>
> double t1 = t0 + 1.0e-6;<br>
> printf("%g\n", t1 - t0);<br>
><br>
> return 0;<br>
> }<br>
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
robocup-small mailing list<br>
<a href="mailto:robocup-small@cc.gatech.edu">robocup-small@cc.gatech.edu</a><br>
<a href="https://mailman.cc.gatech.edu/mailman/listinfo/robocup-small" target="_blank">https://mailman.cc.gatech.edu/mailman/listinfo/robocup-small</a><br>
</div></div></blockquote></div><br></div></div></div>