Comments (6)
The main reason I didn't include it is I don't use it frequently. Since thetaf
doesn't produce a model object but rather a forecast
object directly, we'd have to setup the model estimation in hybridModel
and the forecasting in forecast.hybridModel
somewhat differently for the theta model, and we would be pushing the model estimation and forecasting off at the time of forecasting as well. Essentially we'd probably be estimating the model twice: once in hybridModel
to determine the weights/fitted values/residuals to store in the returned hybridModel
object and once in forecast.hybridModel
. It might be worth opening an issue over in "forecast" to see if Rob would be open to splitting the modeling/forecasting functionality out like in stlm
and stlf
.
It's been a while since I've read it, but Hyndman also shows in an IJF article "Unmasking the Theta method" that theta models can be represented as an ETS, so we might be capturing them already with ets
in the ensemble. Since ets
is a model search procedure, it wouldn't necessarily select the theta model, however, so the ensemble might benefit from the inclusion of thetaf
.
from forecasthybrid.
I've made a start at this in https://github.com/ellisp/forecastHybrid/tree/thetadev . I didn't notice your suggestion we ask Rob to split it out, which I've basically done in thetam
and forecast.thetam
. forecast(thetam(...)
seems to get identical results to thetaf(...)
(tests have been added).
The difference between Theta and ets()
seems to be:
- classical multiplicative decomposition as a first step
- restrict
ets()
tomodel = 'ANN'
. - add drift estimated from linear regression of the seasonally adjusted series on time
I'd be interested to see which of these makes it perform better than ets()
! I suspect it's the drift.
More tests and checks needed before I try to merge into (what's your release strategy for a next version?).
from forecasthybrid.
I haven't had a lot of time to work on this project recently and probably won't for the next few months, so the release question is up to you. The next major feature on my roadmap is parallel support, but I won't have time for that by the next release. That's the biggest remaining missing feature. There are a couple of major changes recently that could support a release (i.e. exporting accuracy.cvts()
and the fix of prediction intervals for nnetar
models). CRAN likes at least 1-2 months between package releases, so although we could release now with those updates, we might want to wait a little longer if you think you can get the theta model into working order by then.
from forecasthybrid.
I'm nearly ready to merge this in. Do you have a preference for new models like theta about including them in the default models string? My inclination is not to, to preserve backwards compatibility and avoid gradual ballooning of the default,, and leave the default "aestn"
.
from forecasthybrid.
Good question. Generally I strongly like to avoid breaking backwards compatibility, but I think it would ok in this instance for a couple of reasons.
- A call to
hybridModel(inputSeries)
would still run and not outright fail. The resulting model wouldn't be exactly what they thought they were getting, but a "soft failure" is much less egregious than a hard failure. - Users can easily maintain the old behavior with
models = "aenst"
. If I were running this in production I'd always specify the setting like this anyway. - The package is still fairly young and without a huge userbase. API changes should be expected during development.
- Documenting the change in the NEWS should be sufficient, along with how to maintain the old behavior.
- Including the theta model will improve forecast robustness, and the model seems to run quickly too.
- We're extending the behavior, not restricting it. All of the model components will still be there if somebody interested with them before, e.g.
$ets
or$nnetar
. Including theta would be somewhat analogous to the model search procedure forauto.arima()
changing: the selected arima order and coefficients might change, but the user could interact with theArima
object in the same way as before.
Overall either approach wouldn't be horrible, but there are some advantages of including it. I do see your point about ballooning the defaults, and that definitely should be a concern, especially if the added models take a long time to run.
from forecasthybrid.
I think this seems sensible. I think the point about how long it takes to run is an excellent one. For example, if we end up importing forecastxgbts
I would be more reluctant to add that to the defaults, because it does take a while to run, at least compared to ets
and theta
.
from forecasthybrid.
Related Issues (20)
- forecastHybrid CRAN update needed HOT 1
- Using forecastHybrid with hts HOT 3
- debug cvts refactor
- unclear forecast value for R timeseries HOT 4
- ts object not recognised in hybridModel of forecastHybrid package HOT 9
- Error with cvts example HOT 2
- Forecast using new ts data and an existing (ie previously fit) model HOT 1
- ExtractForecasts HOT 2
- add snaive model
- Matrix of weights HOT 2
- libcudart version HOT 2
- Error with two regressors HOT 7
- Forecast reconciliation HOT 2
- Restrict to a single core HOT 4
- Adding ARFIMA models.
- Computation of residuals HOT 1
- CV of an hybrid model with xreg.
- Idea: Add Facebook's Pophet model
- CV ggplot2::economics HOT 1
- Error on extractForecasts() from a Hybrid Model with cross validation HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from forecasthybrid.