-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Eric Niebler Sent: 08 August 2007 06:01 To: boost@lists.boost.org Subject: Re: [boost] [time_series] Review

...

time_series_facade.hpp line 262 #ifdef _MSC_VER BOOST_MSVC? Other places too.

I don't know the policy here. I'm disabling msvc-specific warnings. Is there a case when BOOST_MSVC is defined but _MSC_VER is not? And in that case, can I still disable msvc-specific warnings?

...

Something somewhere is suppressing "warning C4244: 'initializing' : conversion from 'double' to 'int', possible loss of data" and not restoring it but I'm not sure whether it's in your library yet.

I'm usually pretty good about pushing and popping the warning levels. If I missed one, it's a bug and I'll fix it.

Mea culpa! I've had trouble with both of these. Does anyone have any ideas on better ways of avoiding 1 using #ifdef BOOST_MSVC when no Boost module has yet been #included and so is not defined. And so you don't get the effect you wanted and need to #ifdef _MSC_VER instead. Easy mistake to make. Is there still a reason why we need to use BOOST_MSVC? (rather than always using _MSC_VER?) 2 failure to push'n'pop warning suppression? I've spotted several mistakes - and worry about others confusing users, especially C4244. How can we check for this automatically? Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Tobias Schwinger Sent: 08 August 2007 11:14 To: boost@lists.boost.org Subject: Re: [boost] BOOST_MSVC versus _MSC_VER

Paul A Bristow wrote:

...

Is there still a reason why we need to use BOOST_MSVC? (rather than always using _MSC_VER?)

Yes: Some compilers (e.g. Intel/Win32) pretend to be MSVC by defining _MSC_VER. Boost.Config defines BOOST_MSVC for the real MSVC only.

I thought as much... But if we are suppressing unwanted warnings, do the pretender MSVCs behave in exactly the same way and all need the same treatment suppressing unwanted warnings? If this is really true, we need a way of ensuring that BOOST_MSVC is *always defined*, perhaps by calling boost config - though this seems a bit OTT? Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Watanabe Sent: 08 August 2007 22:49 To: boost@lists.boost.org Subject: Re: [boost] BOOST_MSVC versus _MSC_VER

AMDG

Paul A Bristow <pbristow <at> hetp.u-net.com> writes:

...

2 failure to push'n'pop warning suppression? I've spotted several mistakes - and worry about others confusing users, especially C4244. How can we check for this automatically?

We can scan each file for the pragmas and check whether every #pragma warning(suppress) is between a #pragma warning push and a pop

I'll look into writing the script and possibly adding it to inspect.

Good - I'm sure this will catch some mistakes that could really confuse users.

What pragmas do other compilers use for suppressing warnings?

I don't know - and hope others can advise, especially the ones cunningly pretending to be msvc ;-) Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com

Michael Fawcett wrote:

On 8/8/07, Eric Niebler <eric@boost-consulting.com> wrote:

...

Steven Watanabe wrote:

...

time_series_facade.hpp line 280 this->sout_ << " value = " << value << ", " << " offset = " << start << ", " << " end offset = " << stop << '\n'; value shouldn't have a space before it should it?

Probably not.

Nit-picky, but "offset" and "end offset" probably shouldn't have spaces before them either since the space is with the comma in the previous line, right?

You're right, of course, but this is really just a debug aid. A general ostream inserter for time series should be more configurable than this. I'm not sure what it should look like exactly, and I'm also not sure if this is a problem the time series library really needs to be solving. -- Eric Niebler Boost Consulting www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com

AMDG Eric Niebler <eric <at> boost-consulting.com> writes:

...

I would partly agree with Stjepan about the dichotomy between sparse/dense series and piecewise constant series. As I see it there are three cases a) sparse/dense and floating point

On the chopping block.

...

b) piecewise constant and floating point c) integral Because of the limits on integers piecewise constant series and point series behave the same way for them. Multiplication makes no sense for point series. Likewise adjacent_difference, integrate, piecewise_sample, piecewise_surface_sample, and index.

I tend to agree, which is why they're not long for this world.

They are still needed for the result of adjacent_difference on piecewise constant floating point series. What do you think of allowing runs to specify what kind of range they use, open, closed or half-open. struct half_open_range : mpl::int_<0> {}; struct rhalf_open_range : mpl::int_<1> {}; // (] struct open_range : mpl::int_<2> {}; struct closed_range : mpl::int_<3> {}; I think that this would allow sparse floating point series to make sense without destroying consistency within the library. In Christ, Steven Watanabe

On 8 Aug 2007, at 16:07, Steven Watanabe wrote:

They are still needed for the result of adjacent_difference on piecewise constant floating point series. What do you think of allowing runs to specify what kind of range they use, open, closed or half-open.

struct half_open_range : mpl::int_<0> {}; struct rhalf_open_range : mpl::int_<1> {}; // (] struct open_range : mpl::int_<2> {}; struct closed_range : mpl::int_<3> {};

I think that this would allow sparse floating point series to make sense without destroying consistency within the library.

Why do you need intervals for sparse series? Sparse series define values only at a finite number of points, and not in intervals? Do you mean piecewise constant series?

Steven Watanabe wrote:

AMDG

Eric Niebler <eric <at> boost-consulting.com> writes:

...

...

I strongly dislike ordered_inserter. Its name indicates to me that it adds elements to a time_series--not at all that it deletes all pre-existing elements. I would expect it to overwrite the old elements only where a new element is specified. That's a valid criticism. Can you suggest a better name?

I can't say that I'm really comfortable with the way ordered_inserter works regardless of the name. I would like it to behave something along the lines of:

The inserter puts elements directly in the series eliminating the need for commit. It is an error when the series has elements after the offset of the inserter. An inserter is invalidated when the container is modified without using the iterator.

It's not exactly what you're asking for, but if you want to modify a time_series in-place, you can do that with range_run_storage::set_at(). It's a terrible way to build a series though, because you need to find the place in the series where this element should be inserted (could be O(log N)) and then insert it (could be O(N)). You seem to be asking for an ordered_append feature. That might be useful to add.

Is there some reason why this doesn't work? If I need the other behavior I can always create a new series fill it and swap myself.

Fill it how? That's exactly what ordered_inserter is for! So you can see, ordered_inserter is necessary. But the name isn't right. The reason for ordered_inserter's existence is that it is the fastest way to build a time_series from scratch, regardless of the internal representation. When you know elements are sorted, you can just bang them into a dense vector, sparse vector, map, or what-have-you -- very efficient. Once you have a time series, there are other ways to manipulate it. The reason for .commit() is that, since you're pushing in one datum at a time, there may be a more efficient intermediate representation than the final time series data structure. For the scenarios I've encountered, being able to efficiently build a series by pushing in one datum at a time is important. The alternative would be use a range-based interface like the STL uses. E.g.: series.assign( from, to ); Here, "from" and "to" can't really be iterators though, or, if they are, they should yield a 3-tuple of (value, offset, end offset). An interface like this is very unwieldy in signal processing, where you often collect data by polling a value at an interval. for(;;) series.push_back(poll_some_value(), last_time, current_time); Of course, push_back() may not be the most efficient way to build up some kinds of data structures. What the ordered_inserter gives is a way have something as efficient as a range-based assign() while retaining the poll-and-push-back convenience. Does that make sense? -- Eric Niebler Boost Consulting www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com

Steven Watanabe wrote:

AMDG

Eric Niebler <eric <at> boost-consulting.com> writes:

...

It's not exactly what you're asking for, but if you want to modify a time_series in-place, you can do that with range_run_storage::set_at(). It's a terrible way to build a series though, because you need to find the place in the series where this element should be inserted (could be O(log N)) and then insert it (could be O(N)).

You seem to be asking for an ordered_append feature. That might be useful to add.

...

Is there some reason why this doesn't work? If I need the other behavior I can always create a new series fill it and swap myself. Fill it how? That's exactly what ordered_inserter is for! So you can see, ordered_inserter is necessary. But the name isn't right.

I would fill it using ordered_append.

How would you suggest ordered_append be implemented?

...

The reason for ordered_inserter's existence is that it is the fastest way to build a time_series from scratch, regardless of the internal representation. When you know elements are sorted, you can just bang them into a dense vector, sparse vector, map, or what-have-you -- very efficient. Once you have a time series, there are other ways to manipulate it.

The reason for .commit() is that, since you're pushing in one datum at a time, there may be a more efficient intermediate representation than the final time series data structure. For the scenarios I've encountered, being able to efficiently build a series by pushing in one datum at a time is important.

Do you have an example where pushing them using a different intermediate representation is significantly more efficient?

Imagine the series storage is std::map<offset, value>. Inserting one value with insert(value) is O(log N). Inserting N values this way is O(N log N). But if you use insert(begin, end), where begin and end are iterators to sorted data, the insert is faster. O(N). So, if you're collecting data one sample at a time (common in signal processing), a good strategy might be to stuff pair<int,value> into a vector or deque first, then do one O(N) insert into your map at the end. That works out to be 2 O(N) operations, rather than one O(N log N) operation. Better. That's a made up example, though. No series types use std::map as a backing store. Rather, they generally use a sorted vector or something. Except delta, characteristic, heaviside and inverse heaviside which don't need growable storage at all. And some series types might not have any storage at all, but just write values to a stream or to disk or something. The point is, you should be able to efficiently be able to write ordered data to a series without any concern for how that data is being stored, or even if it's being stored.

Even if there is such a case should we really use an interface for insertion that departs from established practice even when it isn't needed? Would it be possible to have a range assign function template in addition to the inserter that takes a sequence of tuples? Could this be as efficient as the current ordered inserter?

Yes, and I think this would be good to have. When you have a sorted range of data, it would be nice to have a clean high-level ordered_assign(series, begin, end) that does the series assignment. It can use the lower-level stuff under the covers. But the lower-level stuff is still needed so that series types can be efficiently built in generic code (like the time series algorithms, for instance), which can't make any assumptions.

...

The alternative would be use a range-based interface like the STL uses. E.g.:

series.assign( from, to );

Here, "from" and "to" can't really be iterators though, or, if they are, they should yield a 3-tuple of (value, offset, end offset). An interface like this is very unwieldy in signal processing, where you often collect data by polling a value at an interval.

for(;;) series.push_back(poll_some_value(), last_time, current_time);

Of course, push_back() may not be the most efficient way to build up some kinds of data structures. What the ordered_inserter gives is a way have something as efficient as a range-based assign() while retaining the poll-and-push-back convenience.

Does that make sense?

No.

std::vector<tuple<...> > elements; for(;;) elements.push_back(make_tuple(poll_some_value(), last_time, current_time)); series.assign(elements);

Every element is copied twice.

vs.

ordered_inserter inserter(series); for(;;) *insert++ = make_tuple(poll_some_value(), last_time, current_time); inserter.commit();

Every element is copied once. Have I missed your point, or did you just make mine for me? ;-) -- Eric Niebler Boost Consulting www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com

Steven Watanabe wrote:

AMDG

Eric Niebler <eric <at> boost-consulting.com> writes:

...

How would you suggest ordered_append be implemented?

Mostly copied from dense_ordered_inserter:

<snip> Hmm, yes an in-place append would be a good addition. Agreed.

...

Imagine the series storage is std::map<offset, value>. Inserting one value with insert(value) is O(log N). Inserting N values this way is O(N log N). But if you use insert(begin, end), where begin and end are iterators to sorted data, the insert is faster. O(N).

It is in fact possible to fill a binary tree by pushing sorted data in linear time.

<snip> I don't doubt it. std::map does it for its range-based insert so it must be possible. And this may seem like splitting hairs to you, but what I said is true -- you can't efficiently build a std::map by pushing in sorted data in one element at a time, because the interface doesn't allow for it. You have to pass it a range of sorted elements. You may say, "Well, then don't use a std::map to build a time series!" Fair enough. But when a perfectly satisfactory data structure like std::map cannot be adapted to satisfy a concept, it suggests a faulty concept.

...

The point is, you should be able to efficiently be able to write ordered data to a series without any concern for how that data is being stored, or even if it's being stored.

I don't think you should have *only* a range insert. I think an output iterator that behaves more like std::back_inserter is necessary too.

An in-place append, yes.

...

But the lower-level stuff is still needed so that series types can be efficiently built in generic code (like the time series algorithms, for instance), which can't make any assumptions.

I agree that we need the lower level stuff. I just disagree about *what* lower level stuff.

You're suggesting to replace the ordered_inserter (actually an ordered_assign) with an ordered_append? And perhaps also a clear() member? Or keep ordered_assign? And (crucially) you would do away with commit() on both ordered_assign and ordered_append? Or would you keep them on the low-level interface and add a higher level interface that called commit for you and handled the 90% case? The thoughts I've heard that I like so far are: - add an ordered_append - rename ordered_inserter to ordered_assign - add a higher level interface to make them both easier to use The thought I'm not sold on is: - get rid of commit() on the lower level interface. <snip>

Actually what I would like most is

ordered_inserter inserter(series); for(;;) *insert++ = make_tuple(poll_some_value(), last_time, current_time);

With the additional guarantee that you can process the partial results at any time.

OK. It seems to me that such a thing could be built on top of an ordered_append that has a commit(), simply by calling commit() after every appended element. Would you agree? Thought: it occurs to me that commit() is a bad name. It is evocative of transactional semantics, which is not necessarily accurate. What I'm looking for is a way to signal the end of an input sequence, such that *if* the series has decided to buffer the input, it now knows it has received it all. It doesn't *have* to buffer the input, though. Maybe done() or end() or even eof(). Anyway, the STL-ish assign(begin,end) doesn't have this problem because the end is specified explicitly and it has extra benefits (the size may be known), but this doesn't mesh well with the signal processing domain. In assign(begin,end), the container *pulls* the data. In signal processing, data is often read by polling, and then *pushed* into a container, hence the desire for something like a back_inserter. Time passes ... If we ditched the assigners and the appenders and went with the range-based STL-ish interface, what happens? Any convenient push-based interface we build on top would have to resort to sticking in one value at a time, just like std::back_inserter. Do you really feel that's an improvement? It's an honest question. -- Eric Niebler Boost Consulting www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com

AMDG Eric Niebler <eric <at> boost-consulting.com> writes:

I don't doubt it. std::map does it for its range-based insert so it must be possible. And this may seem like splitting hairs to you, but what I said is true -- you can't efficiently build a std::map by pushing in sorted data in one element at a time, because the interface doesn't allow for it. You have to pass it a range of sorted elements. You may say, "Well, then don't use a std::map to build a time series!" Fair enough. But when a perfectly satisfactory data structure like std::map cannot be adapted to satisfy a concept, it suggests a faulty concept.

Or that the container is not perfectly satisfactory for the particular task. std::map is simply not designed for inserting many elements at the end. Buffering the input still increases the overhead significantly because std::map is not allowed to assume that the input range is sorted. It must check. So using std::map is worse than a custom container for two reasons--it needs temporary storage and it must check the range before inserting it.

And (crucially) you would do away with commit() on both ordered_assign and ordered_append? Or would you keep them on the low-level interface and add a higher level interface that called commit for you and handled the 90% case?

I would remove commit and require buffering to be explicit.

The thought I'm not sold on is:

- get rid of commit() on the lower level interface.

I consider immediate insertion lower level than buffering.

OK. It seems to me that such a thing could be built on top of an ordered_append that has a commit(), simply by calling commit() after every appended element. Would you agree?

I would prefer to implement the "commit" version in terms of the plain version. See below.

Anyway, the STL-ish assign(begin,end) doesn't have this problem because the end is specified explicitly and it has extra benefits (the size may be known), but this doesn't mesh well with the signal processing domain. In assign(begin,end), the container *pulls* the data. In signal processing, data is often read by polling, and then *pushed* into a container, hence the desire for something like a back_inserter.

Just wondering... Isn't it possible to have a pull model from the container's side *and* a push model from the data's side with coroutines?

Time passes ...

If we ditched the assigners and the appenders and went with the range-based STL-ish interface, what happens? Any convenient push-based interface we build on top would have to resort to sticking in one value at a time, just like std::back_inserter. Do you really feel that's an improvement? It's an honest question.

Yes I do. If you want buffering it doesn't have to be done behind the scenes. By adjusting the interface slightly it can be implemented in terms of concepts that already exist. typedef get_efficient_collector<series_type>::type collector_type; collector_type collector; back_inserter<collector_type> inserter(collector); for(;;) *inserter++ = make_tuple(poll_some_value(), last_time, current_time); series.assign(std::move(collector)); In Christ, Steven Watanabe

AMDG Eric Niebler <eric <at> boost-consulting.com> writes:

My point is, the phrase "if you want buffering" doesn't make any sense. The user (or generic algorithm) doesn't know and shouldn't care what the optimal insertion strategy for a given series type is.

Is there any data structure for which buffering actually helps?

Let's back up. Why do you believe that

back_insert (v1, from1, to1) back_insert (v2, from2, to2) back_insert (v3, from3, to3)

should be lower-level than

begin transmission back_insert (v1, from1, to1) back_insert (v2, from2, to2) back_insert (v3, from3, to3) end transmission

?

It is possible to implement either in terms of the other so in a sense neither one is intrinsically "lower-lever." The first is simpler. I do not think the second gains enough flexibility to justify the added complexity. I've just been running some tests with binary trees and the results are surprising. Neither msvc 8.0 nor gcc 3.4 implement the range insertion in linear time for sorted ranges (In spite of the standard). Both just do an element by element insert. Second, I discovered that the map_back_inserter I posted is as fast as a buffered version ( the buffering is insignificant, BTW). In Christ, Steven Watanabe

On 8/12/07, Eric Niebler <eric@boost-consulting.com> wrote:

How does this sound to you? Personally, I wasn't ready to say that appending pre-sorted data is the only scenario that matters; hence, I exposed the more general interface. Perhaps someone more steeped in the time series and signal processing domains could weight in.

If you are collecting data from a number of sources over a network, their time-stamped data can come in out of order. If you know exactly what sort of data to expect, you can wait to get enough to pre-sort and commit to the series, but in some cases either you don't know what sort of data to expect, or things get lost in the network so waiting for something to come is risky. So, appending pre-sorted data may not be the only scenario that matters, if I'm understanding your discussion correctly. Stjepan

AMDG Eric Niebler <eric <at> boost-consulting.com> writes:

I disagree with this. If anything non-trivial is going on in commit(), then the second version cannot be *efficiently* implemented in terms of the first, which means the second is necessarily the more primitive of the two.

If anything interesting is going on in commit() then neither one can be implemented efficiently in terms of the other. I was a bit unclear. I thought that buffering was the only reason for using the second form. Thus, I envisioned template<class T> struct get_buffer_type { typedef no_buffer type; }; template<bool> ordered_assign_impl; template<class T> struct ordered_assign : ordered_assign_impl< is_same<typename get_buffer_type<T>::type, no_buffer>::value

::template apply<T> {};

template<> struct ordered_assign_impl<true> { //use push_back }; template<> struct ordered_assign_impl<false> { //use a range assignment. };

The inserter design (with commit()) came out of a design discussion with Dave A., which I took the time to review this morning. He was coming at the problem from the perspective of MTL4 -- matrices and vectors. For MTL4, he wanted generic ways of representing sparse data and of building sequences. We wanted a mechanism that was general. He imagined a desire to temporarily violate the invariants of a sequence while building it, and then using commit() to "make it good".

<snip>

I see. The inserters make a lot more sense in a larger context. In Christ, Steven Watanabe

Eric Niebler wrote:

Steven Watanabe wrote:

...

...

The inserter design (with commit()) came out of a design discussion with Dave A., which I took the time to review this morning. He was coming at the problem from the perspective of MTL4 -- matrices and vectors. For MTL4, he wanted generic ways of representing sparse data and of building sequences. We wanted a mechanism that was general. He imagined a desire to temporarily violate the invariants of a sequence while building it, and then using commit() to "make it good".

<snip>

I see. The inserters make a lot more sense in a larger context.

Your vote to reject the time series library was based in part on your feeling that the ordered inserter interface was wrong. Now that I've explained the reasons for the interface, does it change your vote?

I'm also interested in your answer to this. John

On 8/8/07, Eric Niebler <eric@boost-consulting.com> wrote:

Here, "from" and "to" can't really be iterators though, or, if they are, they should yield a 3-tuple of (value, offset, end offset). An interface like this is very unwieldy in signal processing, where you often collect data by polling a value at an interval.

for(;;) series.push_back(poll_some_value(), last_time, current_time);

<nit-pick> With the current convention of half-open intervals, wouldn't that be [last_time, current_time), and therefore series[current_time] not be affected by the above insertion? </nit-pick> On a less nit-picky note though, I still can't find a single outside reference in which something that assigns a value to a whole real set interval is called a time series. Eric, you indicated that your choice for using range runs (as opposed to just points, I assume) was that this yielded superior generic algorithms. But in the floating point case, this is causing that most of your structures to represent something that is not really a time series. In rethinking the floating point case, are any of the strategies you are considering looking to put all of your structures in line with what the mathematical notion of what a time series is? In one of your posts, you mentioned something along the lines of making Point concept a first class citizen of the library - IIUTC, that would be a good approach. Furthermore, I think that the RangeRun should be rethought, so that a RangeRun is in effect equivalent to a countable set of Points even in the floating point case (where by "a countable set", I mean "a countable set significantly smaller than the one including every Point indexable by a floating point number between the start offset and end offset"). If not, then I see this as a Time_series+something else library, which is fine. But with time series, I think a continuous interval is much less useful than a way to specify a number of discrete points in an interval. Best regards, Stjepan

On 8/12/07, Eric Niebler <eric@boost-consulting.com> wrote:

Stjepan Rajko wrote:

...

On a less nit-picky note though, I still can't find a single outside reference in which something that assigns a value to a whole real set interval is called a time series. Eric, you indicated that your choice for using range runs (as opposed to just points, I assume) was that this yielded superior generic algorithms. But in the floating point case, this is causing that most of your structures to represent something that is not really a time series. In rethinking the floating point case, are any of the strategies you are considering looking to put all of your structures in line with what the mathematical notion of what a time series is?

Would you agree that the time series types that use integral offsets are isomorphic to what a time series is, in the mathematical sense? Are

Yes

there any time series (in the math sense) that are not representable using integral offsets?

I think that most time-series, and especially those time series used in practice, could be approximated fairly well using an integral-offset series with the appropriate discretization. The problems are: 1) if you don't know much about the series a priori, you might not know what to set the discretization to initially, and might never get a good idea of what the discretization really should be. 2) say you have a series coming at you, and the time intervals between the samples keep getting smaller and smaller, repetitively beating your discretization no matter how small it is. You would have to keep fine_graining, which doesn't seem efficient. 3) a user simply might not want to use discretization. But this is not really a problem when it comes to your lib, because the sparse series with floating point offsets would do the trick.

...

In one of your posts, you mentioned something along the lines of making Point concept a first class citizen of the library - IIUTC, that would be a good approach. Furthermore, I think that the RangeRun should be rethought, so that a RangeRun is in effect equivalent to a countable set of Points even in the floating point case (where by "a countable set", I mean "a countable set significantly smaller than the one including every Point indexable by a floating point number between the start offset and end offset"). If not, then I see this as a Time_series+something else library, which is fine. But with time series, I think a continuous interval is much less useful than a way to specify a number of discrete points in an interval.

I'm having a hard time seeing how this is any different that using a series with integral offsets and a floating point discretization. The time series library provides this functionality already. Can you clarify what you're suggesting?

I don't think that the integral offsets + floating point discretization approach always works (mostly given the problems I list above). But again, sparse_series with floating point offsets can be used instead. I gave a slightly more specific example of what I am suggesting in http://tinyurl.com/ywu53v, but also see below.

I agree that the time series types that use floating point offsets are not very time series-ish in the math sense. But some have expressed the strong opinion during this review that the functionality they provide is useful.

Please don't get me wrong - I also think that the floating point offset series are useful as they are. For example, I think it's really useful to be able to multiply a sparse_series with a piecewise_constant_series, to accomplish something like "multiply all the samples in [0, 100) by 10, and all samples in [100, 200) by 20". Also, I agree with Steven in that the floating point offset series can be divided into two categories - sparse/dense (and delta), which are pretty consistent with the mathematical concept of a time series as they are, with the exception of their pre_runs and post_runs, and the rest, which are closer to modeling a piecewise constant function. What keeps nagging me is that all these "others" are not time series. I wouldn't even call them "series", although they are a series of tuples, because they so much better reflect a piecewise constant function. What I do see coming out of the RangeRun concept is a potentially wonderful foundation for Boost.MathFunction - but in order to get there, it would need to grow (for example, somehow supporting all flavors of open/closed/half-open intervals). So, I see most of these floating point. So all these "others", I see in this limbo - they are not time series, but they are useful to have with time series, and they are almost really nice implementations of piecewise constant functions (and with the potential to implement any function I think, using the RangeRun concept) but not quite there either. So what I'm mostly suggesting is: * whatever is supposed to be a time series - make it a true time series. At the end of the day, anything that is a time series should be convertible to a sequence of discrete time points with values attached, and nothing more. Integral offset versions of the series are there. Floating point versions of dense, sparse, and delta series are also there, except for their pre-runs and their post runs. * whatever is not a time-series - call it something else, or make it clear in the documentation that it behaves as something else in certain circumstances (like floating point offsets). I am not disputing the fact that they are useful, and not suggesting they be removed from the library - they are definitely useful in conjunction with time-series. * alternatively - make everything a time series, which would require you to revisit the RangeRun concept so that it is always convertible to a countable set of discrete (value, time) pairs. The utility I see here is the following: from a time series perspective, I can't just say "All samples in [0, 100) have value 10". I have to specify exactly where all these samples lie. Allowing me to do this concisely using a modified RangeRun would be very useful, since I wouldn't have to specify each of the possibly numerous samples separately, nor would they have to be stored separately.

I guess what I'm missing is a use case for non-integral offsets. Any reanalysis of what floating point offsets mean has to start there. Is it

I hope the above makes a case for some of that. I think in a lot of cases, users will not want to deal with discretization or any involved transforms and just want to use their (value, time) pairs as they are.

simply the desire to index into a sequence of points and interpolate between them in some way? If that's the case, then support for floating point offsets can be dropped in favor of a flexible interpolating facade. (IMO, something like that is needed anyway.)

I have to think about that... I wasn't thinking about that case.

If someone really needs a way to say, "This signal really has the value of X in the time interval [Y,Z)" where Y and Z are floating point values, then continuous floating point runs are the way to go. That seems like a reasonable thing to want, even if it doesn't fit the mathematical definition of "time series".

It is a *very* reasonable thing to want. And it fits the mathematical definition of a function with a domain in the real numbers very well ;-) Best regards, Stjepan