VECM results vs other programmes

[MM72]

Hi,

for some reason, I cannot replicate the results for a simple VECM i get from another econometric package (EViews), and i was wondering if you could tell me why. the model is an unrestricted VECM with one cointegrating vector and 1 lag.

is there something in the way the VECM is set up in Rats that is different from other programmes; in particular, does it make a difference that the ECM equation is estimated outside the VECM with the linreg function?

the impulse responses also look different.

the relevant bit of the code i'm using :

DATA(FORMAT=XLSX,ORG=COLUMNS) 1970:01 2018:04 GDP GDP_LOG GEAR I_GDP_VAR1 I_LOG I_RETURN I_RETURN_LOG RCC $
RCC_LOG TOBQ UNCERT I_LOG_VECM1

linreg(define=ect1) i_log 1988:01 2015:02
# constant rcc_log uncert

SYSTEM(MODEL=VECM1)
VARIABLES I_LOG RCC_LOG uncert
LAGS 1 2
DET constant
ect ect1
END(SYSTEM)
ESTIMATE 1988:01 2015:02

impulse(model=vecm1,steps=60,results=impulses)

[TomDoan]

A couple of things.

1. The convention RATS uses on the number of lags is that it's the number in the VAR itself, not the number of lags on the differences in the VECM which is one less.

2. Yes. It does make a difference how the cointegrating vector is estimated. A maximum likelihood estimate will be different from the Engle-Granger estimate. I would note also that you're including a constant both in the cointegrating vector and in the VECM. Typically, you do one or the other---the former is for a constant restricted to the cointegrating vector (for non-trending series), while the latter is for trending series.

[MM72]

Thanks Tom!

i have modified the code slightly (below); this now gives me IRFs which are close to what the other programme gives.

however, IRFs are not exactly the same, and the forecasts for the variable i'm interested in (i_log) look very different. not sure why this is, could be that the constants are defined differently. notwithstanding the issue you mention with the constants, how would i estimate a VECM with @johmle where i have a constant in both the cointegrating equation and the VECM?

thanks again.

@johmle(lags=2,det=constant,cv=cvector) 1988:01 2015:2
# I_LOG RCC_LOG uncert
equation(coeffs=cvector) ect1 *
# I_LOG RCC_LOG uncert

SET i_log_qq = i_log-i_log{1}

SYSTEM(MODEL=VECM1)
VARIABLES I_LOG RCC_LOG uncert
LAGS 1 2
DET constant
ect ect1
END(SYSTEM)
ESTIMATE 1988:01 2015:02

impulse(model=vecm1,steps=60,results=impulses)

FORECAST(MODEL=VECM1,FROM=2015:03,TO=2018:03,RESULT=FCASTS,STDERRS=STDERRORS,WINDOW='results')

[TomDoan]

That's correct. If you read the EViews documentation, it does a non-standard (i.e. not Johansen) estimate for the cointegrating vector. Perhaps you should bring that up with IHS.

[MM72]

thanks.

actually, managed to get the same results for the unconditional forecasts. i don't think it matters where the constants are in the VECM for the forecast.

however, wondering why i can't produce conditional forecasts as expected. i.e., if i assume i know the path for rcc_log and uncert from 2015:3 to 2018:3, and try to forecast i_log conditional on those dynamically, what exactly does the @condition do? when i try this (below), why isn't the i_log forecast for 2015:3 exactly the same as the unconditional forecast, since the VECM is only using lagged values from 2015:2 (which should be the same for both cond and uncond)?

also, is it not possible to do the forecast performamce analysis with Theil for VECM? i have tried this below and get an error "## MAT1. Matrix Has Not Been Dimensioned The Error Occurred At Location 54, Line 2 of loop/block". is it possible to do the theil loop by also re-estimating the CV with @johmle at each loop?

Thanks again!


@condition(model=VECM1,steps=13,results=condfore) 26
# RCC_LOG 2015:3 RCC_LOG(2015:3)
# RCC_LOG 2015:4 RCC_LOG(2015:4)
# RCC_LOG 2016:1 RCC_LOG(2016:1)
# RCC_LOG 2016:2 RCC_LOG(2016:2)
# RCC_LOG 2016:3 RCC_LOG(2016:3)
# RCC_LOG 2016:4 RCC_LOG(2016:4)
# RCC_LOG 2017:1 RCC_LOG(2017:1)
# RCC_LOG 2017:2 RCC_LOG(2017:2)
# RCC_LOG 2017:3 RCC_LOG(2017:3)
# RCC_LOG 2017:4 RCC_LOG(2017:4)
# RCC_LOG 2018:1 RCC_LOG(2018:1)
# RCC_LOG 2018:2 RCC_LOG(2018:2)
# RCC_LOG 2018:3 RCC_LOG(2018:3)
# uncert 2015:3 uncert(2015:3)
# uncert 2015:4 uncert(2015:4)
# uncert 2016:1 uncert(2016:1)
# uncert 2016:2 uncert(2016:2)
# uncert 2016:3 uncert(2016:3)
# uncert 2016:4 uncert(2016:4)
# uncert 2017:1 uncert(2017:1)
# uncert 2017:2 uncert(2017:2)
# uncert 2017:3 uncert(2017:3)
# uncert 2017:4 uncert(2017:4)
# uncert 2018:1 uncert(2018:1)
# uncert 2018:2 uncert(2018:2)
# uncert 2018:3 uncert(2018:3)


*
theil(model=VECM1,setup,print,steps=12,to=2015:2)

estimate(noprint) * 1999:4

theil(print)
do time=2000:1,2015:2
kalman
theil
end do time

theil(dump,window="Forecast Statistics")
*

[TomDoan]

thanks.

actually, managed to get the same results for the unconditional forecasts. i don't think it matters where the constants are in the VECM for the forecast.

however, wondering why i can't produce conditional forecasts as expected. i.e., if i assume i know the path for rcc_log and uncert from 2015:3 to 2018:3, and try to forecast i_log conditional on those dynamically, what exactly does the @condition do? when i try this (below), why isn't the i_log forecast for 2015:3 exactly the same as the unconditional forecast, since the VECM is only using lagged values from 2015:2 (which should be the same for both cond and uncond)?

@CONDITION is doing exactly what you've asked it to do---give forecasts conditional not just on the past data but on assumed future data. Even if all you provided were the first period values of two of the three variables, the three shocks are correlated, so you would get a different forecast for the third variable using those correlations and the computed values of the shocks for the two conditioned variables. With multiple step constraints, it's even more complicated than that since the shock at period one to i_log will affect the other two variables into the future.

[TomDoan]

theil(model=VECM1,setup,print,steps=12,to=2015:2)

estimate(noprint) * 1999:4

theil(print)
do time=2000:1,2015:2
kalman
theil
end do time

theil(dump,window="Forecast Statistics")
*

THEIL will work---it's KALMAN that's the problem. The error correction model doesn't have a form that allows sequential updating. You'll have to redo the estimation at each step in the loop.

[John]

Tom,
In the theory there is a lon rum realationship between log of futures price (F) and log of spot price (S) in the form of: F=constant + a*S.
And these variables usually have a clear trend.
suppose I a want to estimate the long run relationship. So, I should have a constant both in cointegration equation and the in model. But, Johansen procedure dose not let me to include a constant both in cointegration equation and the in model. According to this procedure I should use this one:

@johmle(lags=??,det=constant)
# F S

How can I estimate such a long run model in RATS?

I have another question about ECT term: In which form will ECT be entered the VECM model?:
a) F-constant-a*S or
b) constant + a*S - F.
I want this because I want to interpret ETC terms.

[TomDoan]

If the series is trending, there is no reason to include a constant in the cointegrating vector. Just DET=CONSTANT. A constant in the CI would simply wash out.

[John]

Thank you very much for your kind help.
In the past, I used Eviews that includes intercept both in CI and in model.
Do you mean that including intercept just in model dose not have any effect on the results? I cannot remember but in some papers like this (Bohl, M. T., Salm, C. A. and Schuppli, M. (2011), Price discovery and investor structure in stock index futures. J. Fut. Mark., 31: 282–306), they have included intercept in both CI and model.

And what about second question ECT term? in ECT instruction it is said that ETC is " intercept + a*S - F". Is it correct for @JOHNMLE procedure too?

[TomDoan]

From my reading of the manual, I believe that EViews "estimates" a constant in the cointegrating vector to zero out the mean. As I said, if you use DET=CONSTANT, the "intercept" in the cointegrating vector washes out. There's no real point to estimating that---statistically, it isn't identified.