ARDL with restriction (zero coefficient on x[t])

[Fifis]

Good afternoon!

I am struggling to find a solution to the problem in EViews 12 (build 2022-04-22): how does one have a variable enter the long-run but not the short-run relationship and still conduct the bounds test for the long-run relationship with all variables?

I am estimating an ARDL(2, 1) model with 3 exogenous regressors:

Y[t] = mu + rho1*Y[t-1] + rho2*Y[t-2] + b10*X1[t] + b11*X1[t-1] + b20*X2[t] + b21*X2[t-1] + b30*X1[t] + b31*X1[t-1] + U

Theory says that b30=0, i.e. there is no immediate response of Y[t] to X3[t]. So X3 enters only the long-run relationship through X3[t-1].

I have been trying to estimate this model, but to no avail:

Code: Select all

equation my.ardl(fixed, deplags=2, reglags=1) y x1 x2 x3

gives the unrestricted model with b30 estimated. Doing my.testdrop l_frin helps, but then, I cannot find a way to save the restricted model and do the long-run test on it.

However,

Code: Select all

equation my.ardl(fixed, deplags=2, reglags=1) y x1 x2 @ x3(-1)

yields the correct model, but then, X3 is not in the EC term, i.e. the test is conducted for Y − (...*X1 - ...*X2), whilst X3 is thrown out. I also tried @fl to specify the fixed lag, as described in https://forums.eviews.com/viewtopic.php?t=18979, but it seems to set the fixed maximum lag with all lags up to the maximum one included. So how do I exclude one specific lag from ARDL estimation (or restrict the coefficient on it to be zero) and still have the full testable EC relationship with all variables? Restricted VARs and VECMs seem to offer facilities for constrained estimation, but I was not able to find it for ARDL.

I should be grateful for a prompt reply.

Yours sincerely,
Andreï V. Kostyrka

[EViews Mirza]

Hi Andrei!

I believe you've explained well what's happening with all the different iterations you've tried. Moreover, you're on the right track with @FL notation, but I'm not sure how you applied it. If I'm not mistaken, the result you're looking for is the following setup:

Code: Select all

equation my.ardl(fixed, deplags=2, reglags=1) y x1 x2 @FL(x3, 0)

This will set y to have 2 lags, x1 and x2 to have 1 lag, and x3 to have 0 lags. In case of the latter, x3 will appear as part of the long-run regressors, but will have no representation among the short-run regressors. In other words, this will NOT set the maximum lag of x3 to 0 (although in this case even such a scenario would lead to the same output), but it forces the lag on x3 to 0, regardless of the lags on other regressors.

I should also mention here that we do not have a way of forcing a coefficient in ARDL estimation to 0. In other words, we don't have anything that resembles "restricted coefficient" ARDL estimation. Rather, any manual restrictions to estimation will be in the form of lag structures.

Please let me know if this fixes things.

[Fifis]

Dear Mirza,

Thank you very much for the prompt reply! I tried your solution, and it yielded an estimated model different from the one for which I would like to test the relationship.

In your example,

Code: Select all

equation my.ardl(fixed, deplags=2, reglags=1) y x1 x2 @FL(x3, 0)

the ARDL model that is estimated in levels has the RHS terms: constant, Y(-1), Y(-2), X1, X1(-1), X2, X2(-1), X3. However, the model with which I am working has X3(-1) instead of X3. I double-checked it in R and EViews via OLS: the long-run coefficients after your suggested model are different from the ones that I have in the theoretical equation and its existing estimated version that I must reproduce exactly. (Also, adding trend=uconst is necessary to replicate the point estimates in the conditional EC regression.)

Your suggestion yields a conditional EC regression onto: constant, DY, DX1, DX2, Y(-1), X1(-1), X2(-1), X3. However, the model I am trying to replicate, with X3(-1) in levels, has the following terms in the conditional EC: constant, DY, DX1, DX2, Y(-1), X1(-1), X2(-1), X3(-1)).

The source of the discrepancy can be shown formally: the long-run relationship coefficients, denoted in the formula below by a, are equal to the following transformation of the ARDL-in-levels coefficients:

Code: Select all

Y = c1*Y(-1) + c2*Y(-2) + b0'X + b1'X(-1) + U DY = r*DY(-1) + e'DX + g*[Y(-1) + a'X(-1)] + U a = (b0 + b1) / (c1 + c2 - 1)

Therefore, unless the sums of the AR and DL parts under the constraint b[X3(-1)] = 0 are exactly proportional to those under constraint b[X3] = 0, the results will be different. The probability of that happenning under normal conditions is zero.

So I am asking more precisely about how to include X3(-1) into the original ARDL(2, 1) equation in levels and to force the coefficient on X3 to be set to zero. This is trivially easy via OLS (just drop X3!), but then, there is no bounds test and no accompanying ARDL-related facilities...

Yours sincerely,
Andreï V. Kostyrka

[EViews Mirza]

Try

Code: Select all

equation my.ardl(fixed, deplags=2, reglags=1) y x1 x2 @FL(x3(-1), 0)

In case of the suggestion above, the ARDL form will be
y = c y(-1) y(-2) x1 x1(-1) x2 x2(-1) x3(-1)

However, the CEC form will be:
d(y) = y(-1) x1(-1) x2(-1) x3(-1) c d(y(-1)) d(x1) d(x2)

[Fifis]

Dear Mirza,

Thank you for your suggestion! I have tried it, and the model in levels is estimated correctly.

However, now, the conditional EC form in the bounds test looks wrong. You were saying that is should have X3(-1) in the CEC form, but when I run it, it is using: constant, DY(-1), DX1, DX2, Y(-1), X1(-1), X2(-1), X3. Somehow, it is still using the contemporaneous value of X3 in the long-run relationship, which is a forward w.r.t. Y(-1), despite the fact that X3 never appeared in the code. Is it a bug that EViews is using the forward value of a variable in this case?

To get from

Code: Select all

Y = c1*Y(-1) + c2*Y(-2) + b0'X + b1'X(-1) + U

to

Code: Select all

DY = r*DY(-1) + e'DX + g*[Y(-1) + a'X(-1)] + U

one uses the following equivalence:

Code: Select all

r = -c2 <=> c1 = r + g + 1 e = b0 <=> c2 = -r g = c1 + c2 - 1 <=> b0 = e a = (b0 + b1) / (c1 + c2 - 1) <=> b1 = a*g - e

Minimal working example that reproduces the error (the data are attached):

Code: Select all

wfopen eviews-support.csv delim=comma @freq U 1 ' True model, ARDL: Y = 0.7*Y(-1) - 0.2*Y(-2) + (0.8 0.7 0)'X + (-0.2 0.15 0.45)*X(-1) + U ' Equivalent ECMX: Y = 0.2*D(Y(-1)) + (0.8 0.7 0)'X - 0.5*(Y(-1) + (-1.2 -1.7 -0.9)*X(-1)) + U equation ols_ardl21.ls Y C Y(-1) Y(-2) X1 X2 X1(-1) X2(-1) X3(-1) series u_ardl21 = resid equation ols_ecmx11.ls Y C D(Y(-1)) D(X1) D(X2) Y(-1) X1(-1) X2(-1) X3(-1) series u_ecmx11 = resid ' These two representations are identical, now we need to get the LR relationship series u_diff = u_ardl21 - u_ecmx11 ' Machine epsilon, as it should u_diff.sheet ' Proof that this is the same model ' From ECMX, we compute the estimated LR elasticities as (-1.32536 -1.59782 -1.00079) ' Pretty close to the true (-1.2 -1.7 -0.9) equation try1.ardl(fixed, deplags=2, reglags=1, trend=uconst) y x1 x2 @FL(x3, 0) series u_try1 = resid series u_diff1 = u_ecmx11 - u_try1 u_diff1.sheet ' Not the same equation try2.ardl(fixed, deplags=2, reglags=1, trend=uconst) y x1 x2 @FL(x3(-1), 0) ' The model fit is the same, so far, so good series u_try2 = resid series u_diff2 = u_ecmx11 - u_try2 u_diff2.sheet ' The residuals are the same, okay try2.ecreg ' But these estimates are not equal to those of ols_ecmx11! try2.cointrep ' Contains the dreaded present value of X3, which is wrong!

Why is this happening?

Yours sincerely,
Andreï V. Kostyrka

[EViews Mirza]

Dear Andrei,

Yes, you've landed on a bug. We'll fix and release an update as soon as possible.

Kind regards,
Mirza

[igor]

Dear Mirza, dear Andreï

I'm not sure if this is a bug. First, @FL(x3(-1), 0) supposes that lag is zero, so in the long-run equation x3 will be included by definition. Secondly (and the most important), the main idea of this procedure is to test for long-run relationship (cointegration). Therefore, any exclusions of lags at the beginning or between the lags structures seems questionable. For instance, we don’t do this in Johansen cointegration test. Why should we do this here? I think we have to test for cointegration using optimal (or fixed) lag structure and then make manually any manipulations with lags in EqCM.

Just for fun one can try @FL(x3(-1), 1): x3(-1) will be in the long-run and Dx3 – in the short-run and then can be excluded as insignificant.

Best regards,
Igor