From: Eric Niebler (eric_at_[hidden])
Date: 2006-12-14 13:46:10
Darryl Green wrote:
> I (tried to) send this yesterday but some prob with my mailer.
> I see the idea of nulls has been discussed a bit by Matt Hurd and James
> Eric Niebler wrote:
> > I think the current framework can handle this situation quite
> naturally. The offsets need not be integral multiples of the
> discretization. The offsets can be floating point, which can be used to
> represent exact times. Or as Jeff Garland suggested, the offset could in
> theory be a posix ptime (not tested). That way you wouldn't have to pass
> around a separate vector representing the times, or make your data tuple
> with times.
> It was only when I read this that I took another look at the docs and
> realized that your library is using a non-uniform sampling model. This
> is interesting - but could make some algorithms hard to write and/or
> much less efficient?
I think you misunderstood, or I was unclear. The library accommodates
both uniform and non-uniform sampling. In another reply, I wrote:
> Yes, I think what is there already can be pressed into service to
> achieve the same effect. Conceptually, a TimeSeries (as defined by
> Boost.Time_series) is two sequences: the elements and the runs. The
> elements are the values of the time series, and the runs are a sequence
> of (offset, end offset) pairs [*]. And the offsets can be integral or
> floating point (or ptimes, I guess). So if I'm understanding correctly,
> all we need is a flexible way to view the elements of one time series
> given the runs of another. Does that make sense?
> [*] Obviously, a time series doesn't need to be stored in memory that
> way, so long as it's able to present that interface. A sparse series
> need not store end offsets, and a dense series need not store any
> offsets at all -- the runs sequence can be generated on the fly.
Take the case of a dense_series. It has uniform sampling. Its "runs"
sequence has the property of being "dense", meaning that each run is of
unit length, and the run offsets are monotonically increasing.
Obviously, finding a sample with a particular offset in a dense series
is O(1), but not in a sparse series. Algorithms can test for density
using a trait and select an optimal implementation. The default
implementation would handles series with non-uniform sampling.
It's all done using compile time traits, so there is zero runtime overhead.
-- Eric Niebler Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk