[SciPy-User] synchronizing timestamps from different systems; unpaired linear regression

Charles R Harris charlesr.harris@gmail....
Wed Apr 11 11:53:20 CDT 2012


On Wed, Apr 11, 2012 at 10:37 AM, Nathaniel Smith <njs@pobox.com> wrote:

> On Wed, Apr 11, 2012 at 5:16 AM, Chris Rodgers <xrodgers@gmail.com> wrote:
> > Re Nathaniel's suggestion:
> > I think this is pretty similar to the algorithm I'm currently using.
> Pseudocode:
> >
> > current_guess = estimate_from_correlation(x, y)
> > for timescale in decreasing_order:
> >  xm, ym = find_matches(
> >    x, y, current_guess, within=timescale)
> >  current_guess = linfit(xm, ym)
> >
> > The problem is the local minima caused by mismatch errors. If the
> > clockspeed estimate is off, then late events are incorrectly matched
> > with a delay of one event. Then the updated guess moves closer to this
> > incorrect solution. So by killing off the points that disagree, we
> > reinforce the current orthodoxy!
>
> Yes, that's why I was suggesting doing something similar to your
> current algorithm, but different in ways that might avoid this problem
> :-).
>
> > Actually the truest objective function would be the number of matches
> > within some specified error.
> > ERR = .1
> > def objective(offset, clockspeed):
> >   # adjust parametrization to suit
> >   adj_y_times = y_times * clockspeed + offset
> >   closest_x_times = np.searchsorted(x_midpoints, adj_y_times)
> >   pred_err = abs(adj_y_times - x_midpoints[closest_x_times])
> >   closest_good = closest_x_times[pred_err < ERR]
> >   return len(unique(closest_good))
> >
> >
> > That function has some ugly non-smoothness due to the
> > len(unique(...)). Would something like optimize.brent work for this or
> > am I on the wrong track?
>
> That also has the problem that the objective function is totally flat
> whenever the points are all within ERR, so you are guaranteed to get
> an offset inaccuracy on the same order of magnitude as ERR. It sounds
> like your clocks have a lot of jitter, though, if you can't do better
> than 10 ms agreement, so maybe you can't get more accurate than that
> anyway.
>
>
I'd like to know the platform. The default Window's clock ticks at 15 Hz,
IIRC.

<snipL

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-user/attachments/20120411/fc7b6ffc/attachment.html 


More information about the SciPy-User mailing list