Block Exogeneity Test

[sguerra]

Dear Users,

I just want to request a little help about the Block Exogeneity test sugested on page 342 of the RATS Readers Manuals.

This test has a null hypothesis that the lags of one set of variables do not enter the equations for the remaining variables.

In the example sugested above, the rats manual shows how 3 real variables are as a block exogenuos. (GDPQ UNEMPRATE, GPDI)

Example VARCAUSE.PRG

(Please take your time to see the example)

The test just exclude nominal variables (GDPDEFL{1 to 4} and M2{1 to 4}) that you may incorporate as deterministics, and then you test using the RATIO instruction if those laged variables help to explain the whole system.

My question then is, WHY the manual tell us that the test is trying to see the Exogeneity of REAL variables?

Thanks for your help

Sergio Guerra

[TomDoan]

The test is whether the nominal variables enter the real equations. The null is that they don't, which means that the real variables don't respond to nominal shocks - they form an exogenous block.

[Alberto]

Hi,
regarding the block exogeneity tests, I wonder if you could explain a bit more what is mentioned in the User Guide (version 7, p.347): " (...) some hypotheses might have a non-standard distribution in the presence of unit roots (Sims, Stock and Watson, 1990). Their result (...) will affect the exogeneity tests (Example 10.2)". The example VARCAUSE.PRG includes some variables in log-level, some of which have a unit root.
The question is then, is there any correction to be implemented in the presence of unit roots? does the example VARCAUSE.PRG work for VARs with variables in levels without any further change?
Thanks
Alberto

[TomDoan]

An example of bootstrapping for a (bivariate) Granger causality test is provided at https://estima.com/forum/viewtopic.php?f=8&t=2323.
This can be extended fairly easily to a block test.

[Alberto]

Thanks, this is useful. However, not being familiar with the function "group" used in the programme I have a doubt in translating the programme to the case of multiple variables (say, the case of varcause.prg). Would one have to specify each equation of the VARs (restricted and unrestricted) to create a model for the group function to be simulated or is there a more compact way?
Alberto

[TomDoan]

Thanks, this is useful. However, not being familiar with the function "group" used in the programme I have a doubt in translating the programme to the case of multiple variables (say, the case of varcause.prg). Would one have to specify each equation of the VARs (restricted and unrestricted) to create a model for the group function to be simulated or is there a more compact way?
Alberto

You could set up two VAR systems and combine them; one would be like the unrestricted model in example 10.2, the other would be a standard VAR on the exogenous variables. However, it would probably be easier to just set up the equations that you need directly.

[Alberto]

All right. Then, the bootstrap for the varcause.prg could look like the attachment, right?
Alberto

[TomDoan]

That looks fine, except that you want to pull to outside the loop the SYSTEM...END(SYSTEM) that define the UNRESTRICTED and RESTRICTED models in terms of the resampled data. Those definitions just set the form of the model---there's nothing wrong with changing the data to which they apply after defining the model but before estimating.

Also, given that you're doing 10000 draws, it might help to speed the calculations up a bit. The following (which is hardwired for your setup) will compute the test statistic off a single cross product matrix. It might cut the time by around 40%. You would just need to define UNRESTRICTED (outside the loop), then put this inside after the resampled data has been created and replace everything down through the RATIO instruction:

cmom(model=unrestricted)
compute sweepxx=%sweeptop(%cmom,13)
compute sigmares=%xsubmat(sweepxx,22,24,22,24)/%nobs
compute sweepxx=%sweeplist(sweepxx,%seq(14,21))
compute sigmaunr=%xsubmat(sweepxx,22,24,22,24)/%nobs
compute %cdstat=(%nobs-21)*log(%det(sigmares)/%det(sigmaunr))

[Alberto]

OK, thanks.
For reference I add the two programmes, one with the correction indicated and another with the suggested change to make it faster (in this case one saves just a few seconds, but I assume with more variables the savings may be more substantial).
Alberto

[TomDoan]

dear
in vec(2) model ,such as
yt =b11yt-1+b21yt-2+b31xt-1+b41xt-2+b51ecmt-1
xt =b12yt-1+b22yt-2+b32xt-1+b42xt-2+b52ecmt-1
how to perform the a two variable causality test using the bootstrap method?

Is the cointegrating vector known? If so, everything in the above system is stationary (I assume that x and y's are actually differenced) so you can test causality by doing a simple exclusion restriction. For testing a null that y doesn't cause x, that would mean excluding the lagged y's and the error correction term.

[iloverats]

dear
in vec(2) model ,such as
yt =b11yt-1+b21yt-2+b31xt-1+b41xt-2+b51ecmt-1
xt =b12yt-1+b22yt-2+b32xt-1+b42xt-2+b52ecmt-1
how to perform the a two variable causality test using the bootstrap method?

Is the cointegrating vector known? If so, everything in the above system is stationary (I assume that x and y's are actually differenced) so you can test causality by doing a simple exclusion restriction. For testing a null that y doesn't cause x, that would mean excluding the lagged y's and the error correction term.

dear Tomm
help me
there are 2 quesitons
in your meanning i just modify your code like this, am i right ?

linreg(define=eqm) x / rx
# constant x{1 to 8}
linreg(define=eqg) y / ry
# constant x{1 to 8} y{1 to 8} ecm{1}
*
group noncausal eqx eqy
*
compute ndraws=10000
set stats 1 ndraws = 0.0
do draws=1,ndraws
*
* Resample the residuals over the regression range
*
boot entries %regstart() %regend()
set xsample = rx(entries(t))
set yample = ry(entries(t))
forecast(paths,model=noncausal,from=%regstart(),to=%regend(),results=results)
# xsample ysample
set xsample = results(1)
set ysample = results(2)

..........

2.i think this do not make sense
when i resampling the x and y through the bootstrapping, the ecm also shifts
because the ecm is the residual of (x=b*y+e)


Merry Christmas

[iloverats]

The significance level produced by a standard LR test 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 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-stationary 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 1 lag, the unit root properties can still be expressed. An exogeneity hypothesis isn't OK, since the series can't be cointegrated if one is in an exogenous block---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. I've attached an example of bootstrapping a two variable causality test, which can be extended fairly easily to a block test.

grangerbootstrap.prg

(This uses the same data set and same hypothesis as the causal.prg example from the manual).

Note that there is a "non-fix" to the problem in

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

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.

if the variables fm1 and gdph are unstationary(have unit roots) , is the F used for non-Granger Causality statistically valid?

[TomDoan]

if the variables fm1 and gdph are unstationary(have unit roots) , is the F used for non-Granger Causality statistically valid?

That's covered by the very first sentence. The "F" is still the proper test statistic, but it has a non-standard distribution.

[Coribe]

I am also wondering about this question from above:

"2.i think this do not make sense when i resampling the x and y through the bootstrapping, the ecm also shifts
because the ecm is the residual of (x=b*y+e)".

Is is possible to include an equation to also bootstrap the ecm or include an identity that specifies the long-run relation between the two variables?

[TomDoan]

I am also wondering about this question from above:

"2.i think this do not make sense when i resampling the x and y through the bootstrapping, the ecm also shifts
because the ecm is the residual of (x=b*y+e)".

Is is possible to include an equation to also bootstrap the ecm or include an identity that specifies the long-run relation between the two variables?

In the context of the exogeneity test? The BOOTCOINTEGRATION.RPF example does bootstrapping for the estimate of a cointegrating vector. That does block bootstrapping to handle the short-run part of the model.