Re:. Re: [Gretl-devel] VECM restrictions once again
by andreas.rosenblad＠ltv.se
r.lucchetti(a)univpm.it @ INTERNET skrev 2007-09-05 14:06:49 :
> This is a consequence of the fact that in gretl the scaling factor for
the
> covariance matrix is T (sample size), whereas apparently eviews uses
(T-p)
> (degrees of freedom). Not sure what PcGive does, but it would seem that a
> factor of (T-p-1) is used (maybe lags?).
>
> Of course, all choices are asymptotically equivalent, but in this
> case the difference is noticeable because the sample size is rather
> small; maybe we could change policy in gretl and use (T-p) instead?
Or, even better, let the user choose if he/she should use T, (T-p) or
(T-p-1)?
Andreas
18 years, 1 month
- 3
- 5
gretl and X-12-ARIMA
by andreas.rosenblad＠ltv.se
Dear gretl developers,
FYI, the version of X-12-ARIMA available from the gretl web site is 0.2.10,
but there is now a new version 0.3 available from the U.S. Census Bureau.
Best regards
Andreas
18 years, 1 month
- 2
- 1
VECM restrictions once again
by Allin Cottrell
Hello all,
I've been spending time on this topic lately. The current target
is for gretl to support:
(a) General restrictions on VECM beta: not necessarily
homogeneous, and possibly differing across the cointegrating
relations (where the cointegrating rank > 1). But excluding
cross-equation restrictions.
(b) Homogeneous restrictions on VECM alpha, possibly differing
across the equations.
(c) Combinations of the above.
We're getting close. We've implemented both a limited-memory BFGS
optimizer and the Boswijk-Doornik switching algorithm. On current
evidence the latter seems preferable.
But there are still some weird things to sort out. Perhaps I can
illustrate with a gretl script (which should work with current CVS
or the current Windows snapshot). Take Johansen's Danish data.
<script>
open denmark
vecm 2 1 LRM LRY IBO IDE --rc --seasonals
restrict
b1 + b2 = 0
end restrict --full
# The "--full" flag results in the creation of a new VECM
# system subject to the restriction in question.
# Now test a second restriction "within" the first:
restrict
b3 + b4 = 0
end restrict --verbose
# Re-estimate the basic system
vecm 2 1 LRM LRY IBO IDE --rc --seasonals
# Maintain the previous beta restrictions, and add
# a restriction on alpha.
restrict
b1 + b2 = 0
b3 + b4 = 0
a[3] = 0
a[4] = 0
end restrict --verbose
# Fine, except for two things:
# (1) It would be nice to have the results normalized
# (2) It would be nice to have standard errors for beta
# To achieve these things we try adding a normalization
# saying that the first beta term = 1
restrict
b1 = 1
b1 + b2 = 0
b3 + b4 = 0
a[3] = 0
a[4] = 0
end restrict --verbose
# Ah, but now the results are bad. We fail to get close to
# the true ML solution. If we go back to the previous result
# and manually normalize to beta[1] = 1, we get the following
# initialization:
matrix B0 = { 1, -1, 5.8, -5.8, -6.2 }'
matrix A0 = { -0.14, 0.13, 0, 0 }'
matrix U = B0 | A0
set initvals U
restrict
b1 = 1
b1 + b2 = 0
b3 + b4 = 0
a[3] = 0
a[4] = 0
end restrict --full
</script>
The final "restrict" command produces nice results. But what has
gone wrong in the previous case? Clearly the automatic initial
values computed by gretl were bad. But can anyone test this
against other software and see if the competition gets it right?
That would be very helpful.
One other thing: I'm not forgetting Sven's suggestion that we
support adding "restricted" exogenous variables. This is
feasible, it's just that there are many places in the code where
it's assumed that (a) there's at most one additional restricted
term in the cointegration relation(s), and (b) that it's either a
constant or a trend. That should be fixable with some work, but
right now I'm focused on the beta and alpha tests.
Allin.
18 years, 1 month
- 3
- 4