Rolling-VAR-MGARCH-M

[hasanov]

Hi Tom,
From your posts, you seem to support expanding window approach over rolling window. Is there any reference for this in the literature?

Note, BTW, that "rolling sample" GARCH models are really not a good idea. Fixing the start, and moving the end to do simulated out-of-sample forecasts has some value. Moving the start along with the end isn't well-motivated.

Many thanks

[hasanov]

Hi Tom,

I want to include univariate tests in the loop using zu(1) and zu(2) of "stdresids=zu" produced in the garch instruction.

Code: Select all

correlate(qstats, number=5) zu(1)
compute qstats1(regend) = %QSTAT
compute qstatsignif1(regend) = %QSIGNIF

correlate(qstats,number=5) zu(2)
compute qstats2(regend) = %QSTAT
compute qstatsignif2(regend) = %QSIGNIF

However, it returns the following error message.

## REG11. Regression Position 11 Should Be Between 1 and 6
The Error Occurred At Location 1412, Line 67 of loop/block

What could be the cause for this error?

Thank you

[TomDoan]

Hi Tom,
From your posts, you seem to support expanding window approach over rolling window. Is there any reference for this in the literature?

Note, BTW, that "rolling sample" GARCH models are really not a good idea. Fixing the start, and moving the end to do simulated out-of-sample forecasts has some value. Moving the start along with the end isn't well-motivated.

Many thanks

Fixed start-moving end is what the Kalman filter does for linear models and there is an obvious reason for using it, as the estimates through time T won't be correlated with out-of-sample forecast errors for T+1 to T+h. A better question is what the point is for a moving window for something like a GARCH model. Is there any model for the data that justifies it?

[TomDoan]

Hi Tom,

I want to include univariate tests in the loop using zu(1) and zu(2) of "stdresids=zu" produced in the garch instruction.

Code: Select all

correlate(qstats, number=5) zu(1)
compute qstats1(regend) = %QSTAT
compute qstatsignif1(regend) = %QSIGNIF

correlate(qstats,number=5) zu(2)
compute qstats2(regend) = %QSTAT
compute qstatsignif2(regend) = %QSIGNIF

However, it returns the following error message.

## REG11. Regression Position 11 Should Be Between 1 and 6
The Error Occurred At Location 1412, Line 67 of loop/block

What could be the cause for this error?

Thank you

That wouldn't be from those instructions---probably from a TEST instruction. Look at line 67 in the loop (note the information on the location of the error).

[hasanov]

Hi Tom,

As indicated in the User's Guide, @MVGARCHFore procedure produces out-of-sample variance forecasts for many standard MGARCH models. Does this also apply to MGARCH model estimated with skew t distribution ?

Thank you

[hasanov]

Hi Tom,

I am using @mvarchtest within the loop:

@mvarchtest(lags=5)
# zu
compute mvarch(regend) = %CDSTAT
compute mvarchsignif(regend) = %SIGNIF

I am facing the following issue after some the loop calculations:

## MAT14. Non-invertible Matrix. Using Generalized Inverse for SYMMETRIC.
The Error Occurred At Location 651, Line 59 of MVARCHTEST
C:\USERS\mvarchtest.src Line 87
Called From Location 2014, Line 38 of loop/block

Do you have any idea on how to settle this issue? Is it because I am using mvarchtest.src ? Was there any update in this source?

Many thanks for your anticipated input.

[TomDoan]

The cross products of the lags produce a singular matrix (@MVARCHTEST runs a multivariate regression of cross products on lagged cross products, so it can be pretty big). How long is your estimation window, and how many variables do you have in the model?

[hasanov]

Thanks for your reply !!

I am using the recursive (i.e., expanding) window with a three-variable model.
Initial estimation window size is 2300 observations then it increases by 5 in every iteration until it reaches 3850.
The problem arises when multivariate skew t and/or t distributions are used in the estimations. However, there is no issue with multivariate normal and GED.

[TomDoan]

Clearly something isn't working correctly. If you are running with a NOPRINT option, turn that off so you can see what is actually happening.

[hasanov]

Is that the following without 'noprint' option?

@mvarchtest(lags=5, print)
# zu
compute mvarch(regend) = %CDSTAT
compute mvarchsignif(regend) = %SIGNIF

[TomDoan]

What matters most is the GARCH instruction. Something must be failing badly there.

[hasanov]

Hi Tom,

I removed the loop part of the code to understand the following issue.

## MAT14. Non-invertible Matrix. Using Generalized Inverse for SYMMETRIC.
The Error Occurred At Location 651, Line 59 of MVARCHTEST
C:\Users\Public\Documents\Estima\WinRATS Std 10.0\mvarchtest.src Line 87

Would you please have a look at what is causing this problem with distrib=GED and distrib=t. The code is running with "distrib=norm" without any issue.

Attached the data and code.

Many thanks

[TomDoan]

Have you looked at your data? RETS1 has a couple of one period 20+ standard deviation spikes followed by immediate corrections. Offhand they look like data typos. There is no way a GARCH model can explain that. Basically, maximum likelihood is going to do everything it can to explain 4 data points out of roughly 1200. Your t estimates don't converge because the t is going to push the degrees of freedom towards 2 (where the log likelihood is no longer computable). Your oil price series is basically step function for the last few years, rather than moving day to day. Again, that's not the behavior of a GARCH process.

rets1.pdf

(12.07 KiB) Downloaded 665 times

[hasanov]

Hi Tom,

The following piece of code works fine to forecast Ht matrix elements.

@MVGarchFore(MV=BEKK, steps=step) hh rv
*
do i=1,step
compute hhat11(regend+i) = hh(regend+i)(1,1)
compute hhat22(regend+i) = hh(regend+i)(2,2)
compute hhat12(regend+i) = hh(regend+i)(1,2)
end do i

In addition to the above, I want the code to compute VAR forecasts (returns) and save in the pre-created object in every window as I did with hhat11 or hhat22.

I would be appreciated if you could give some guidance on this matter.

Regards

[TomDoan]

Are you still doing an "M" model? There isn't a closed form out-of-sample forecast for that.