The RATS Software Forum

Dear Tom,
I would like to estimate an SVAR model which is an extension of the Blanchard and Quah’s decomposition to the case of 3 or 4 variables (i.e. the long-run response (3*3) o r(4*4) matrix is lower triangular). To practice myself with all the RATS codes and procedures, I built a little program and procedure named SRLRDoDraws .src (based on different programs and procedures found on the Estima’s website). Armed with this program, I try to recover the IRF and errors bands of the BQ’s papers. And here, I met one problem:
- I obtained exactly the BQ’s paper IRF (without the errors bands) with the following lines:
@ShortAndLong(lr=lr,sr=sr,masum=inv(%varlagsums),factor=f) vsigma
compute f=%dmult(f,||%sign(f(1,1)),%sign(f(1,2))||)
@varirf(model=varmodel,steps=nsteps,factor=f,page=all, shocks=shocklabels,varlabels=varlabels,accumulate=||1||)
(this is the figure 1)
- but when I try to compute the errors bands (with Monte Carlo integration) I cannot recover the right IRF of the GNP and Unemployment to the supply shock (and the errors bands seem uncorrect) with this part of the code:
@SRLRDoDraws(accum=||1||,steps=nsteps,model=varmodel,lr=lr,sr=sr)
@MCProcessIRF(model=varmodel,percentiles=||.05,.95||,center=mean,lower=lower,upper=upper,irf=irf)
(this is the figure 2)
What is strange for me is that I recover the right IRF of the GNP and Unemployment to the demand shock on the right column of figure 2, but not the right IRFs to the supply shock (left column of figure 2). However, earlier in the program when I use @varirf, the IRFs to both shocks are consistent with BQ figures (figure 3 and 4, p 663 of the AER paper)
Do you have any idea why in the second graph the IRFs to the supply shock are not correct ?
Thank you in advance,
Best,
Romain

That's an interesting point. The RATS code for draws in the BQ model corrects the sign only for a demand shock (making sure demand doesn't have a negative impact on GNP). Your program corrects the signs of both. For the original estimates, it doesn't matter. However, when you do the MC integration, it's not that uncommon for the BQ factor to have a negative impact on GNP. If you correct both signs, somewhat interestingly, the "supply shock" isn't as much of a supply shock as it is if you keep the original sign---if you have a factor with a negative impact on GNP, it almost always turns positive relatively quickly. So if you flip the sign on that, it starts positive and goes negative, hence the "supply shock" having effects of rather uncertain sign. Because the supply shock is really the "whatever shock is orthogonal to the demand shock", it's not easy to tell why that's the case.

Looking at the results in the paper, it's possible that they simply discarded draws with a negative impact on GNP---it has a similar shape to the one that the RATS code generates but without having any negative impacts, but given the dynamics, discarding would be quite different from sign flipping.

Needless to say, demand shocks match because those are always getting their signs corrected.

Thanks Tom for your interesting reply. I never thought it could come from the point you raised in your reply. I must think about it much harder. If I find a solution to fix the problem, I will let a new message on the forum.
Best
Romain

Tom,
I compared my own procedure SRLRDoDraws with BQDoDraws.src (available on RATS' website). The two are identical (it's not a suprise since I used existing programms to built my own procedure) except for the computation of the factor of the long-run matrix. While I use the function @shortandlong, the BQDoDraws.src constructs this factor with %bqfactor.
Do you think that this simple and unique difference between the 2 procedures can explain why I cannot recover the IRF when I compute the errors-bands for the supply shock with SRLRDoDraws.src (while BQDoDraws.src does it correctly) ?
Thanks.
Romain

There's absolutely nothing wrong with what you're doing. This is all a matter of figuring out what the proper sign convention is for the "supply shock". And that's apparently not all that clear.