The RATS Software Forum

GRANGERBOOTSTRAP.RPF is an example of doing a Granger causality test with bootstrapped confidence values. (This is included with RATS v9 and uses the same data set as CAUSAL.RPF).

The significance level produced by a standard LR test for causality isn't correct (that is, the test statistic isn't asymptotically chi-squared) if there are some series in each block which have unit roots. The result in Sims, Stock and Watson(1990) can be understood as meaning that hypotheses which don't somehow restrict the unit root behavior of the variables have standard asymptotics, while those that do have non-standard asymptotics. Thus, the lag length tests are OK (at least as long as you aren't trying to test 1 vs 0), since as long as you have at least 1 lag, the unit root properties can still be expressed. An exogeneity hypothesis isn't OK---the zero restrictions affect possible unit root behavior.

The true asymptotics would have to be evaluated on a case by case basis, so bootstrapping is a better approach. GRANGERBOOTSTRAP.RPF does a parametric bootstrap under the null hypothesis.

Note that there is a "non-fix" to the problem in Toda and Yamamoto(1995). In short, it tests for "causality" by adding lags to a VAR (to allow for possible unit roots/cointegration) and then tests zero restrictions which don't include those added lags. Rather than fixing the Sims-Stock-Watson problem, it actually confirms their results that most coefficients and linear combinations thereof are asymptotically normal, but that certain restrictions which eliminate channels of influence for unit roots aren't.

By adding extra lags and then not testing them, the "bad" behavior is shifted onto the untested lags. In effect, you're no longer testing lack of causality, since that requires testing all the lags. While their test statistic has the correct distribution under the null (which the SSW results would predict), it will suffer badly from lack of power since, if the block of coefficients aren't, in fact, zero, the "causality" will get shifted fairly easily to the untested lag(s) since an integrated process is so highly autocorrelated.

See https://estima.com/forum/viewtopic.php?f=5&t=2116 for a statistically valid alternative to bootstrapping.


Sims, C.A., J.H. Stock, and M.W. Watson (1990). “Inference in Linear Time Series Models with
Some Unit Roots”, Econometrica, Vol. 58, No. 1, pp. 113-144.

Toda, H.Y., Yamamoto, T., 1995. "Statistical inference in vector autoregression with possibly integrated processes." Journal of Econometrics 66, 225-250.

Dear Tom,

does this code replicate the following study of Balcilar?

http://link.springer.com/article/10.100 ... 012-0562-8

Thanks,
N.K

Many thanks Tom. please find attached paper.

Regards,
N.K

(Attachment removed)

As you can see if you read the paper, they do indeed use a bootstrapped version of the Toda-Yamamoto test, which is discussed both above in this thread, and in the other thread.

Hi, Tom, for the grangerbootstrap, how could combine the code with a rolling process (fixed-sixe window), as the paper above did? Thanks in advance!

Rolling window (anything) are handled as described in the User's Guide. If you want to do that (note that before you go to the trouble, you should do a test for stability of the VAR first), I would recommend using the Geweke-Meese-Dent version of the causality test which has standard asymptotics, so you don't have to bootstrap within the rolling windows.

Hellow,


I want to use the @VARBootDraw, to do bootstrapping on a VAR-GARCH model, for the residuals I use the ones obtained from the garch(...) command. But about the input model, I don't know if the command is using the mean model of the VAR-GARCH or simply the VAR. If it's the second option, how could I fix it?.

A multivariate GARCH bootstrap is much more complicated than that. The residuals from a GARCH model can't be reshuffled as is since they have a complicated dependence pattern. (@VARBootstrap assumes the residuals are serially uncorrelated with a fixed covariance matrix, so you *can* simply redraw those, as long as you keep them together at a single time period). Instead, you have to invert the GARCH model recursion to get residuals without serial dependence in the variance (those are the jointly standardized residuals), reshuffle the standardized residuals, then use the GARCH model to rebuild a set of residuals with the desired GARCH properties. Those then can be fed into the VAR to get rearranged data. An example (without the VAR part, though that's by far the easiest part of this) is GARCHMVBOOTSTRAP.RPF.