Implementing component GARCH process
This implements the Engle & Lee 1999 Components GARCH model which decomposes volatility into long term and short term components.
A lot of change has been in the volatility.py and recursion.py files but parts of base.py and mean.py have been modified but only slightly to handle a volatility process that generates two volatility series.
Tests have been added to test forecasting, representation, recursion, and estimation of CGARCH.
Forecasting is enabled for CGARCHbut only analytical method. Other methods will be included later.
One example has been put in the Examples folder and the docs have been changed where needed to show the new functionality.
Coverage decreased (-0.5%) to 98.238% when pulling 580ae56a05dc44d56470edd8eab90b22b5958e8b on RichardMM:master into ef52881a78bc5a13c3e9b15bbf7c809dd5ab7601 on bashtage:master.
Coverage decreased (-0.5%) to 98.238% when pulling 580ae56a05dc44d56470edd8eab90b22b5958e8b on RichardMM:master into ef52881a78bc5a13c3e9b15bbf7c809dd5ab7601 on bashtage:master.
Codecov Report
Merging #188 into master will decrease coverage by
2.27%. The diff coverage is77.77%.
@@ Coverage Diff @@
## master #188 +/- ##
==========================================
- Coverage 99.36% 97.08% -2.28%
==========================================
Files 72 35 -37
Lines 13285 8728 -4557
Branches 1131 780 -351
==========================================
- Hits 13201 8474 -4727
- Misses 28 159 +131
- Partials 56 95 +39
| Impacted Files | Coverage Δ | |
|---|---|---|
| arch/univariate/base.py | 93.13% <47.22%> (-4.50%) |
:arrow_down: |
| arch/univariate/recursions_python.py | 84.87% <72.72%> (-13.73%) |
:arrow_down: |
| arch/univariate/volatility.py | 95.77% <75.92%> (-3.39%) |
:arrow_down: |
| arch/univariate/mean.py | 92.97% <80.00%> (-5.34%) |
:arrow_down: |
| arch/univariate/recursions.pyx | 94.64% <85.71%> (-5.36%) |
:arrow_down: |
| arch/tests/univariate/test_volatility.py | 99.76% <96.87%> (-0.24%) |
:arrow_down: |
| arch/utility/array.py | 81.81% <0.00%> (-13.81%) |
:arrow_down: |
| arch/unitroot/unitroot.py | 93.39% <0.00%> (-5.51%) |
:arrow_down: |
| ... and 71 more |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing dataPowered by Codecov. Last update 3dcaed2...f0f65c5. Read the comment docs.
Thanks for making these changes. I'm not sure this is the simplest method to implement Component GARCH since the standard Component GARCH is just a restricted GARCH(2,2). This said, I hanve't carefully reviewed these changes and so these might be more general.
I didn't want to modify the GARCH class to allow for a restricted GARCH(2,2) because it's a really loaded class, adding it there would make it even more complicated, so I opted for a separate class altogether. Thanks for the response
I think it should be possible to subclass GARCH setting p=q=2, and then overwriding some of the methods to specialize for the different parameter interpretations (e.g. that starting values, likelihood, etc). I think many of the methods, aside from handelign the mapping between CGARCH parameters and GARCH(2,2) parameters, will be unchanged. These could be written in a manner like
def some_func(self, params):
tparams = self._transform_params(params)
return super(CGARCH,self).some_func(tparams)
With subclassing , I think it would get problematic with methods that deal with the long term component e.g compute_variance and _analytic_forecast because how would one change the super(CGARCH,self).some_func(tparams) to return the long term component even if we transform parameters.
Coverage decreased (-0.5%) to 98.196% when pulling 1d2d55a42d26af41b789a8d068f4d6dea3ba3c50 on RichardMM:master into 3d3b390a8fd53f341ef667366d2bf3f3ed71e005 on bashtage:master.
Hello, are you still considering this pull request?
Coverage decreased (-0.5%) to 98.179% when pulling f0f65c5a5401e05e27c7d681f9b487254e0b8f53 on RichardMM:master into 2db76fa8478f4cbca0620e0c12495b70e7e280e6 on bashtage:master.
Coverage decreased (-0.5%) to 98.179% when pulling f0f65c5a5401e05e27c7d681f9b487254e0b8f53 on RichardMM:master into 2db76fa8478f4cbca0620e0c12495b70e7e280e6 on bashtage:master.
I haven't forgotten about this -- just been quite busy.
Hello; Is there anymore needed from my end
Hi guys,
Is this topic still being pursued?