separate arma and arima implementations

[papamarkou]

With the latter being a function wrapper of the former.

[milktrader]

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]

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]

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

[papamarkou]

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]

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

[ElOceanografo]

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 [email protected]:

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//issues/27#issuecomment-43744590
.

[papamarkou]

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]

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.