Boost logo

Boost :

From: Matt Hurd (matthurd_at_[hidden])
Date: 2006-12-13 16:42:53

>On 14/12/06, james.jones_at_[hidden]
<james.jones_at_[hidden]> wrote:
>So interpolation certainly isn't *always* appropriate.

For sure. My original post referred to being able to choose a what I
call a matching algorithm for inputs with different clocks.

In spending a few years writing these kinds of apps, >99% of the time
for my needs the most recent time <= matching time was the one used if
clocks were different. Though others certainly make sense. The next
most often used was what I called a correlated match where the output
stream reflects only those times where all inputs had a time in
common. Some of the philosophy there was to reflect the actions of a
reactive dataflow system.

Using nulls would be a both complementary or alternative approach.
I've typically avoided nulls for missing data as it complicates the
integration with third party libraries too much. Most math,
scientific or stats libs either don't support nulls or have different
ways or representing missing values or nulls.

That said, I think it makes sense to allow the support of nulls in a
time series library as it is a design that makes sense. I could also
imagine a matching algorithm that "injects" nulls for non-matched
times. Complicates things a bit when you want include algorithms and
representations that are not null aware as you'd like the type system
to reject the composition of such at compile time.



Boost list run by bdawes at, gregod at, cpdaniel at, john at