The RATS Software Forum

Dear Tom,

just a quick question regarding a post above, which is about estimating a Threshold Near-VAR. You mentioned that it would be either possible to use SUR with the splitted sample and adding the two likelihoods or using simply a full VAR and the SWEEP instruction to estimate the threshold. Estimation of the slope coefficients of the near VAR for the different regimes would then be done using the estimated threshold from the full VAR.

What would be the effect on the log likelihoods? Would both methods pick the same threshold or would the estimated thresholds be just very similar?

Thank you

Best Jules

Adding the log likelihoods from separately estimated SUR's across the subsamples gives the log likelihood for the full sample.

There's no reason for them to be the same, but they probably will be similar.

Dear Tom Doan,
When I run the tvar_irf.prf code, I got the following error.
## SX22. Expected Type EQUATION or FRML[REAL], Got VECTOR[FRML[REAL]] Instead
>>>>group tvar tvarf <<<<
I couldn't solve this problem. I'm hoping you could give me some suggestion how to fix it.
Thank you in advance!

The ability to use the TVARF on its own in the GROUP instruction is coming with the next build of 9.20. For now, you need to expand that to

group tvar tvarf(1) tvarf(2) tvarf(3) tvarf(4) thrfrml upperfrml

Dear Tom,

I have three questions regarding the specification of TVARs.

1)
Balke uses a delay d=1 for the threshold variable. Is it possible to use some criterium to specify that?
My idea was to fix the number of lags for the VAR equations and the sample size by setting a maximum number for the threshold delay (dmax). Then I would estimate the TVAR for all threshold delays (d<dmax) and compare the resulting likelihoods. The threshold delay that generates the largest likelihood would then be chosen.

2)
In the Balke test code, the delay of the threshold variable is ordered and used for estimation: why is this the case? The sweep instruction within the estimation loop uses "group=credthr{d}<thresh". But thresh is already lagged due to "set copy rstart rend = credthr{d}".

3)
For the estimation of IRFs, dup is set to "set dup = thrfrml{d}>thresh". Why do we choose thrfrml{d} here and not simply thrfrml{0}?
I understand why we use "thrfrml{d}" in the switching formula, but I do not understand why the delay is used for the upper regime dummy.

Many thanks

Jules

Jules89 wrote:Dear Tom,

I have three questions regarding the specification of TVARs.

1)
Balke uses a delay d=1 for the threshold variable. Is it possible to use some criterium to specify that?
My idea was to fix the number of lags for the VAR equations and the sample size by setting a maximum number for the threshold delay (dmax). Then I would estimate the TVAR for all threshold delays (d<dmax) and compare the resulting likelihoods. The threshold delay that generates the largest likelihood would then be chosen.

Sure. The most common approach in threshold models is to pick the D that produces the most significant test statistic for a break, but since this is linear model, actually estimating isn't a huge cost.

Jules89 wrote: 2)
In the Balke test code, the delay of the threshold variable is ordered and used for estimation:

Code: Select all

set copy rstart rend = credthr{d}
order copy rstart rend

why is this the case? The sweep instruction within the estimation loop uses "group=credthr{d}<thresh". But thresh is already lagged due to "set copy rstart rend = credthr{d}".

copy is a sorted copy which provides the possible break values; that's all.

Jules89 wrote: 3)
For the estimation of IRFs, dup is set to "set dup = thrfrml{d}>thresh". Why do we choose thrfrml{d} here and not simply thrfrml{0}?
I understand why we use "thrfrml{d}" in the switching formula, but I do not understand why the delay is used for the upper regime dummy.

Because the dummy is selecting subsamples based upon the switching criterion.

Note that this example is covered in rather substantial detail in the 2nd edition of the Switching Models/Structural Breaks course.

Dear Tom, I´m starting in Rats and I have doubts.
I need to estimate a TVAR with four variables and I notice in the tvar_irf.rpf that it shows only the responses of output growth to shocks in each variable.
How Can I get the responses of the other variables and not only output growth ?

pbrigante wrote:Dear Tom, I´m starting in Rats and I have doubts.
I need to estimate a TVAR with four variables and I notice in the tvar_irf.rpf that it shows only the responses of output growth to shocks in each variable.
How Can I get the responses of the other variables and not only output growth ?

Sure. The 1 in red is the series 1 that makes this the response of output growth (the first series). Change it to 2, and you get the responses of the second variable, etc.


*
* Graph response of output growth (variable 1) to all four shocks.
*
dec vect[series] graphs(nexp)
*
spgraph(vfields=nvar,hfields=1,footer=$
"Response of Output Growth to Shocks, Conditional on "+$
RegimeDesc,key=below,klabels=shocksizel,style=line,$
ylabels=shortlabels)
do j=1,nvar
do k=1,nexp
move nlirfs(k)(1,j) wstart wend graphs(k) 1
end do i
graph(series=graphs,number=0,picture="##.#")
end do j
spgraph(done)

Dear Tom,

Thanks !

I need to solve another doubt:

Where do I need to change for the lower regime besides this:

* Change to upper =0 to get the Lower regime
*
comp upper =0
comp regimeDesc ="Tight Regime"
*
Is there another change to do ?

No. That's it.

Dear Tom,

I modify the code and I note that the impulse-response functions (NLIRF´s) are the same, both for the high and the low. I think I'm doing something wrong. By chance, I should change for the lower regime as it is below :

* Create a FRML to determine which regime holds in a simulation. (It
* will be 1 for upper and 0 for lower)
*
frml(identity) upperfrml dup = thrfrml{d}>thresh

for:

frml(identity) upperfrml dup = 1.-dup

Thanks

No. That's just wrong. (That's a circular definition of dup). The only change is to the two lines at the top.

If you're applying this to your own data, and you're getting similar results for the high and low regimes, then you probably don't really have a break (at least with the threshold variable that you're using).

Dear Tom,

I am working on a TVAR with 2 regimes.

However, there is a following problem:

For the upper regime (upper=1) the results are normals. But, for the lower regime (upper=0), it return, continuosly, the following error messages:


The Error Occurred At Location 490, Line 29 of loop/block
## FO19. Forecast for DLPIBREAL solves to NA at 1997:04, on iteration 1.
The Error Occurred At Location 490, Line 29 of loop/block
## FO19. Forecast for DIPCA solves to NA at 1997:04, on iteration 1.
The Error Occurred At Location 490, Line 29 of loop/block
## FO19. Forecast for DCAMBIOR solves to NA at 1997:04, on iteration 1.
The Error Occurred At Location 490, Line 29 of loop/block
## FO19. Forecast for CREDIT solves to NA at 1997:04, on iteration 1.
The Error Occurred At Location 490, Line 29 of loop/block
## FO19. Forecast for DSELICR solves to NA at 1997:04, on iteration 1

no stop on the screen

Can you say me where I´m wrong ?

Here is the code and data.

Greatful !

The program asks for dados7_94.xls, but you attached dados8_96.xls. With the latter, this seems to work OK, so I'm thinking that there's something wrong with the other data file (perhaps around 1997:4).

Sorry, Tom !

I forgot to modify the file.

Now, it´s right. But, the error remains...

Greatful