TimeSeries.jl icon indicating copy to clipboard operation
TimeSeries.jl copied to clipboard

Polymorph vs. non-polymorph methods

Open QuantLandi opened this issue 10 years ago • 3 comments

There are some methods that work on single-column timearrays only: percentchange, moving, upto, collapse as far as I noticed so far.

So, as long as you pass some single-column timearray as argument (ex: moving(cl, mean, 10), where cl comes from the MarketData package), everything goes fine. However, if you pass some multiple-column timearray (ex: moving(ohlc, mean, 10)), you get an error. This does not happen with lag and lead.

When it comes to element-wise mathematical and comparison operators (as per their definition in the doc), if you pass some multiple-column timearray (ex: ohlc ./ ohlc) you get no error but you get your expected result only for the first column of the time-array you passed instead of the whole timearray.

Is this a deliberate choice? Wouldn't it make sense for such methods to be able to receive n-columns timearrays as argument?

QuantLandi avatar Aug 04 '15 12:08 QuantLandi

https://github.com/JuliaStats/TimeSeries.jl/pull/197 actually implements element-wise math operations over all columns in 2D TimeArrays, although the PR's kind of stalled since the jury's still out on switching to AbstractArrays. I would agree that we should strive to support operations on both 1D and 2D TimeArrays (and consistent behaviour across combinations thereof) wherever it makes sense.

GordStephen avatar Sep 12 '15 14:09 GordStephen

Yeah, this is an important feature that one can reason about. R does this. And Julia is better than R :smile:

Jury is in on AbstractArrays: good to go.

I'll get 0.6.0 ready and @GordStephen you can begin implementing this, if you have the time. A good way to do this (and the way I use even when I'm the only contributor) is to create a PR and let some comments accumulate.

milktrader avatar Sep 12 '15 23:09 milktrader

percentchange, moving, and upto now support both 1D and 2D inputs and are tested accordingly, and collapse will as well once #244 is merged, so I think we're close to finally addressing this completely - but before this is closed it's probably worth going through every function in the package to make sure that both 1D and 2D inputs are both supported and tested against.

GordStephen avatar Jan 09 '16 02:01 GordStephen