search

JuliaStats / TimeModels.jl

Modeling time series in Julia
Other
57 stars 28 forks source link

separate arma and arima implementations #27

Open papamarkou opened 10 years ago

papamarkou commented 10 years ago

With the latter being a function wrapper of the former.

milktrader commented 10 years ago

I'm in favor of this but it appears R has opted not to support this (at least I can't find it). There is an ar function and an arima function in R but no arma. They require the user to pass a 0 for the d argument.

milktrader commented 10 years ago

I can file a separate issue for this, but exactly what fitting method is currently used? Regression (OLS, MLE)? There is some literature that shows the Burg method is superior to these two, and to Yule-Walker as well. http://www-stat.wharton.upenn.edu/~steele/Courses/956/ResourceDetails/YWSourceFiles/WhyNotToUseYW.pdf

milktrader commented 10 years ago

By way of context for this issue, R's forecast package offers ar, ma and arima but not an arma.

papamarkou commented 10 years ago

We don't need to emulate R in terms of the source code, unless you think that there is a relative advantage by using R's approach. My view would be that arma should be the main function, and then ar, ma and arima should all be wrapped around arma. I am not sure what has been implemented as of yet in terms of the fitting method, we should ask San Urmy who wrote the relevant code. I think we should provide all available methods and let the user choose which one to invoke via an optional argument.

milktrader commented 10 years ago

I think R not supporting an arma function is more a cultural artifact, so agreed we don't need to follow that example.

ElOceanografo commented 10 years ago

Sorry I'm late to the discussion--I wasn't on email yesterday. The function arima_statespace constructs a matrix state space representation of an arbitrary (univariate) ARIMA model. As it says in the comment, the code came pretty much straight out of Brockwell and Davis. The corresponding R function is makeARIMA, which I haven't really looked at. The fitting method (in Kalman.jl) is just a wrapper around optimize() at the moment, maximizing the likelihood.

My personal preference is to have one interface to classical time series modeling via an arima() function, with optional arguments for fitting methods etc. It's true that differencing the series first gives you the same thing with an ARMA model, but I think many users, especially those coming from R, will expect a function called "arima." And in the classical time-series context, that's generally taught as the most general type of model. I say we make "d" a keyword argument defaulting to 0 and call it good...I think having both arima and arma functions is potentially confusing.

One of the things that bugs me about R's time series functionality is how it's pretty fragmented--this was especially a problem for me when I was learning both R and time series analysis at the same time. My ideal TimeModels package would be able to handle problems across a gradient of complexity, from simple AR to multivariate state space models, in a reasonably unified/consistent framework. In my head, it would be really nice to have functions for time series analagous to lm() and glm() in the regression context, with a simple interface but access to a wide range of models.

All that said, I will be in the field for much of this summer, starting next week...so I will be otherwise occupied for the next couple of months, and only in intermittent contact with the internet. So feel free to disregard and/or press ahead on anything without me :)

On Wed, May 21, 2014 at 7:51 AM, milktrader notifications@github.comwrote:

I think R not supporting an arma function is more a cultural artifact, so agreed we don't need to follow that example.

— Reply to this email directly or view it on GitHubhttps://github.com/JuliaStats/TimeModels.jl/issues/27#issuecomment-43744590 .

papamarkou commented 10 years ago

I agree with your views on the interface. Of course the interface is separate from the underlying implementation to a big extent. We can create the arima function interface as the wrapper around arma. This would allow a cleaner implementation while maintaining a unified interface.

milktrader commented 10 years ago

After thinking about this for a day, I'm in favor of both an arma and arima methods, with the latter wrapping the former. The arima will be there for those familiar with that interface. By splitting out the core code into arma we allow experimental transformations to be easily implemented, say using square root vs differencing, e.g.