7:32 a.m.
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
8:49 a.m.
New subject: [Gretl-users] VECM estimation
Riccardo Jack Lucchetti schrieb:
Sven, I'm cc-ing this to the developer list because I think
it's the best
place for this discussion
I wasn't aware of this list, it's not on the web.
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.
Right, I meant as a quick hack just for me to help, not as a real
feature of gretl.
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.
A quick check doesn't show any problems, exactly the same output. I
suspect that you get bitten by different conventions w.r.t. lag
specification, deterministics etc.
But I don't have Johansen's book with me here right now, so what's the
exact specification you're having trouble with?
If you could do the same with MicroFit too, that'd be great.
Sorry I don't have that. I meant only Jmulti and pcgive.
-sven
9:20 a.m.
New subject: VECM estimation: gretl vs JMulTi
On Thu, August 31, 2006 10:49, Sven Schreiber wrote:
> 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.
A quick check doesn't show any problems, exactly the same output. I
suspect that you get bitten by different conventions w.r.t. lag
specification, deterministics etc.
But I don't have Johansen's book with me here right now, so what's the
exact specification you're having trouble with?
Attached you will find gretl's and JMulTi's output for what I believe should
be the same model. You will see the numbers are similar, but definitely not
something you could blame floating-point rounding for. I am using JMulTi 4.04,
as the latest version doesn't like my version of java.
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
10:07 a.m.
New subject: VECM estimation: gretl vs JMulTi
Riccardo Jack Lucchetti schrieb:
Attached you will find gretl's and JMulTi's output for what I believe should
be the same model. You will see the numbers are similar, but definitely not
something you could blame floating-point rounding for. I am using JMulTi 4.04,
as the latest version doesn't like my version of java.
Ok I can reproduce that. As I suspected, the difference seems to relate
to deterministic terms, namely the treatment of seasonals.
It very much looks like the seasonals in Jmulti are not centered, which
makes a difference if you have a restricted constant, as you know.
So this is a problem of Jmulti which is not nice at all, and thank you
for pointing it out. I'll contact Markus (the jmulti man) about it, but
I think he's on vacation right now.
-sven
10:29 a.m.
New subject: VECM estimation: gretl vs JMulTi
On Thu, August 31, 2006 12:07, Sven Schreiber wrote:
Ok I can reproduce that. As I suspected, the difference seems to
relate to
deterministic terms, namely the treatment of seasonals.
It very much looks like the seasonals in Jmulti are not centered, which
makes >
a difference if you have a restricted constant, as you know.
So this is a problem of Jmulti which is not nice at all, and thank you for
pointing it out. I'll contact Markus (the jmulti man) about it, but I think
he's on vacation right now.
Well spotted.
I am including a revised version of the script to test linear restrictions on
beta to match what JMulTi does. Note:
1) as you said, this is not the proper way to do it; with a restricted
constant, seasonals must be centered
2) in my previous version I had swapped the last two arguments to pvalue; now
it's ok (degrees of freedom come first)
3) right after the vecm command, comes an example on how to test the same
hypothesis via LR
# ---------- begin script ----------------------
open denmark
genr dummy
vecm 2 1 1 2 3 4 ; dq1 dq2 dq3 --rc
restrict
b1 + b2 = 0
b3 + b4 = 0
end restrict
matrix b = $jbeta
matrix V = $jvbeta
matrix R = { 1, 1, 0, 0, 0 ; 0, 0, 1, 1, 0 }
scalar df = rows(R)
matrix W = R * b
matrix R = R[,2:5]
matrix V = R * V * R'
scalar WT = W' * inv(V) * W
printf "Wald test: %g (%d df, pvalue = %g)\n", WT, df, pvalue(X,df,WT)
# ----------- end script -----------------------
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
7:57 a.m.
New subject: VECM estimation: gretl vs JMulTi
Riccardo Jack Lucchetti schrieb:
On Thu, August 31, 2006 12:07, Sven Schreiber wrote:
> Ok I can reproduce that. As I suspected, the difference seems to relate to
> deterministic terms, namely the treatment of seasonals.
>
> It very much looks like the seasonals in Jmulti are not centered, which
makes > a difference if you have a restricted constant, as you know.
> So this is a problem of Jmulti which is not nice at all, and thank you for
> pointing it out. I'll contact Markus (the jmulti man) about it, but I think
> he's on vacation right now.
Well spotted.
fyi, starting with version 4.13 Jmulti now also uses centered seasonals
in vecm estimation (it always had done so in the cointegration test
module). Thank me for annoying Markus until he gave up ;-)
-sven
6972
days inactive
7012
days old
5 comments
2 participants
participants (2)
-
Riccardo Jack Lucchetti -
Sven Schreiber