[robocup-small] New Referee Box Protocol

[Ben Johnson]

Oops, I was wrong about vision: it uses a double storing seconds.
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.

On Fri, Nov 9, 2012 at 3:18 PM, Christopher Head <chead at chead.ca> wrote:

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