Re: [Gretl-users] VECM estimation
by Riccardo Jack Lucchetti
Sven, I'm cc-ing this to the developer list because I think it's the best
place for this discussion
On Wed, August 30, 2006 21:31, Sven Schreiber wrote:
>> the matrices S00 & co. are quite easy to build by combining lists, loop, genr
>> and matrix functions; all in all, you need moment matrices of residuals. On
>
> Sure, but dealing with sample lengths, lagged differences, exogenous
variables etc. is not fun and it's already implemented in a nice dialog, so
why not use it?
Well, because IMO it doesn't "feel" like a good idea to have too many
fetchable variables post-estimation. It's a balancing act here: a few things
would be simple to do in a script, but you're likely to use them a lot (think
$uhat), some other things would be more cumbersome (example: $jbeta) so we
might as well make them fetchable once estimation is over for the user's
convenience, even if you're unlikely to use them except in few special
situations. In my mind S00 & co. belong to neither group, but I'm open to be
convinced of the contrary.
>> Note that we can already do this via a LR test.
>
> Where is that documented?
Well, it seems it isn't. :-(
But basically, this is what "restrict" does after "vecm"; the corresponding
GUI element is "Test/Linear restriction" from the VECM output window.
It looks like the manual needs to be beefed up a little. Actually, a chapter
on hypothesis testing wouldn't hurt.
>
>> While I tested this, I realised that I couldn't reproduce Johansen's
results
>> with JMulTi; either I'm missing something, or JMulTi's VECM estimation goes
through a different algorithm from ours. We do VECMs as per Johansen's
book;
>> so does PcGive, and I believe there should be no differences between our
results and what PcGive yields.
>
> I have all those programs, do you want me to test/confirm something?
Please try to reproduce the Denmark example you find in Johansen's book. The
data are available as denmark.gdt among gretl example datasets. JMulTi seems
to do strange things with VECMs. I exported the denmark dataset to JMulTi
format via the new ad-hoc facility: then, I could reproduce the same results
we have in gretl for almost everything (descriptives, VARs, etc.) but VECMs
proved impossible. I understand you know the main developer of JMulTi
personally: it may be a good idea to ask his opinion if/when we're certain
that results are indeed different.
If you could do the same with MicroFit too, that'd be great.
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
17 years, 11 months
current CVS changes
by Allin Cottrell
As I try to get 1.6.0 ready, I'm also keeping an eye on the
changes that will come with 1.6.1, in particular a big change in
the way "genr" works internally.
With this in mind, I've recently changed a few things
pre-emptively, so there's not so much to be altered after the
1.6.0 release. Probably the most relevant change to date is
that, for random filling of matrices you now use
muniform(rows, cols)
mnormal(rows, cols)
The point is that under the new scheme these functions, which
return matrices, will have to be distinct from normal() and
uniform(), which return series. This is because genr will be
more flexible with regard to the handling of variant types,
on which more later...
Allin.
18 years
omit command
by Riccardo Jack Lucchetti
While playing with large datasets, I found that the "omit" command wouldn't
work for a particular model: I got a "Data error" message. Some investigation
led me to discover (I didn't know before) that, in order for the omit command
to work, you need to have the same number of observations for both the
unrestricted and the restricted model. Same goes for "add".
The reason for this is that the test that gets computed by these commands
involves comparing the two models, which is ok. However, for large datasets,
this is a very serious limit: when you have many variables and thousands of
observations the likelihood of having missing values in some of the
added/omitted variables is very high.
Now, this can be bypassed via "restrict", which does a Wald-style test, but if
you want to exclude dozens of variables at the same time (think of industry
dummies, for instance), it's not the handiest of tools.
Therefore, my proposal (which probably involves some work, but not much): how
about appending a --wald option to "omit", by which we carry out the test by
the "restrict" machine instead of the default?
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
18 years