Austin Bingham wrote:
Like many other posters, I'm excited to see this work being done. Not to be shown up by Zach, I also have a few questions about the library.
First, it's not entirely clear to me whether arithmetic operations between series with different non-integer discretizations is allowed. From the documentation:
Arithmetic operations between series is only defined when the series have the same discretization. When the discretization is a plain integer, the discretizations are checked for compatibility at runtime.
If I'm reading this correctly, arithmetic between unequal non-integer series is undefined but not checked at runtime. If so, why isn't it checked?
It is checked. That's a doc bug. It should read, "When the discretization is not a compile-time constant, the discretizations are checked for compatibility at runtime."
Along those lines, I can envision a situation where I *would* want to do the kind of arithmetic described above. In some applications, the notions of time and range are effectively interchangeable. If I have two "time series", one discretized on range and one on time but both representing the same physical space, I might reasonably expect to be able to add them together. I realize I'm stretching a bit here, but I want to get your sense of how things like this might be dealt with in this library.
I'm afraid I don't follow. What do you mean by a time series "discretized on range"?
Does the clip() function necessarily copy the source data? It's often nice to be able to generate a sliced view of some source data without actually copying it. I assume clip() does copy, so I was wondering if there is a facility for prodcing non-copying views of a time series.
clip() does *not* copy the data. It returns a clipped view. If you want to copy the data, you should assign the clipped view to another series.
Again, I really like the work you've done so far, and I'd love to have a robust, high-feature time-series library. I'll keep looking things over and let you know if I've got any more questions.
Thanks. Keep the questions coming. -- Eric Niebler Boost Consulting www.boost-consulting.com