From cottrell@wfu.edu Thu Aug  9 22:33:02 2007
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] VECM restrictions once again
Date: Thu, 09 Aug 2007 22:34:02 -0400
Message-ID: <Pine.LNX.4.64.0708092149310.16607@ricardo.ecn.wfu.edu>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4803901423391350926=="

--===============4803901423391350926==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

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.

--===============4803901423391350926==--


From svetosch@gmx.net Fri Aug 10 07:35:52 2007
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] VECM restrictions once again
Date: Fri, 10 Aug 2007 11:35:53 +0100
Message-ID: <46BC3F89.3000304@gmx.net>
In-Reply-To: Pine.LNX.4.64.0708092149310.16607@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5911209375812400191=="

--===============5911209375812400191==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin Cottrell schrieb:
> Hello all,
> 
> I've been spending time on this topic lately.  The current target 
> is for gretl to support:

Great to hear that, I appreciate it very much.

...

> 
> 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.  

So this would prove their claims correct?

> 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.

I would, but I will be traveling the next 2-3 weeks.


-sven

--===============5911209375812400191==--


From cottrell@wfu.edu Fri Aug 10 11:02:06 2007
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] VECM restrictions once again
Date: Fri, 10 Aug 2007 11:03:06 -0400
Message-ID: <Pine.LNX.4.64.0708100837260.31812@ricardo.ecn.wfu.edu>
In-Reply-To: 46BC3F89.3000304@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4799990613739242146=="

--===============4799990613739242146==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Fri, 10 Aug 2007, Sven Schreiber wrote:

> > 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.  
> 
> So this would prove their claims correct?

To an extent.  We're able to come up with some cases where the 
switching algorithm gets stuck at a local maximum but this may 
have more to do with the initialization than the optimization
method itelf.

> > 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.
> 
> I would, but I will be traveling the next 2-3 weeks.

OK, hope to hear from you later!

Allin.

--===============4799990613739242146==--


From svetosch@gmx.net Wed Sep  5 06:28:20 2007
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] VECM restrictions once again
Date: Wed, 05 Sep 2007 10:28:16 +0100
Message-ID: <46DE76B0.4060307@gmx.net>
In-Reply-To: Pine.LNX.4.64.0708100837260.31812@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6006859675156134749=="

--===============6006859675156134749==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin Cottrell schrieb:

>>> 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.
>> I would, but I will be traveling the next 2-3 weeks.
> 
> OK, hope to hear from you later!
> 

Ok, hope you don't miss this belated continuation of the thread.

Before tackling the restrictions, maybe it's worth noting that for the
unrestricted Vecm I get the same point estimates with gretl (snapshot
downloaded today), Eviews (5.1), and PcGive (10.4), but three different
sets of standard errors:

gretl:
beta (cointegrating vectors, Standardfehler in Klammern)

LRM(-1)           1.0000
                (0.00000)
LRY(-1)          -1.0329
                (0.12805)
IBO(-1)           5.2069
                (0.50735)
IDE(-1)          -4.2159
                 (1.0051)
const            -6.0599
                (0.79464)

Eviews:
	
LRM(-1)	 1.000000
	
LRY(-1)	-1.032949
	 (0.13897)
	[-7.43297]
	
IBO(-1)	 5.206919
	 (0.55060)
	[ 9.45682]
	
IDE(-1)	-4.215879
	 (1.09082)
	[-3.86489]
	
C	-6.059932
	 (0.86239)
	[-7.02691]

PcGive:
beta
LRM                 1.0000
LRY                -1.0329
IBO                 5.2069
IDE                -4.2159
Constant           -6.0599

Standard errors of beta
LRM                0.00000
LRY                0.14054
IBO                0.55682
IDE                 1.1031
Constant           0.87213



Now turning to the restrictions in the top post:

Eviews and PcGive produce the correct results, saying "6 iterations" and
"strong convergence" (with settings eps1=0.0001) respectively. They are
identical to each other and also match gretl's output, except for the
standard errors of the adjustment coefficients which are a little
smaller in gretl.

Do you do any scaling before the switching algorithm? The beta
coefficients differ by a factor of 6 (haven't looked at the
--detrended-- variables themselves), maybe that explains something. (I
always used the gretl example data exported to the other formats, so
maybe there's also some conversion loss, but I doubt it.)

By the way I also tried with my unpublished py4gretl_vecmrestrict2 (the
published version w/o the 2 at the end cannot handle this case), but I
don't get any results, but no error message either. So some other
function-package related bug must be lingering there, but leave that for
another time...

HTH,
-sven


--===============6006859675156134749==--


From r.lucchetti@univpm.it Wed Sep  5 08:04:33 2007
From: Riccardo (Jack) Lucchetti <r.lucchetti@univpm.it>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] VECM restrictions once again
Date: Wed, 05 Sep 2007 14:04:29 +0200
Message-ID: <alpine.DEB.0.999.0709051358450.15547@ec-4.econ.univpm.it>
In-Reply-To: 46DE76B0.4060307@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0175630777029392229=="

--===============0175630777029392229==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Wed, 5 Sep 2007, Sven Schreiber wrote:

> Allin Cottrell schrieb:
>
> Ok, hope you don't miss this belated continuation of the thread.
>
> Before tackling the restrictions, maybe it's worth noting that for the
> unrestricted Vecm I get the same point estimates with gretl (snapshot
> downloaded today), Eviews (5.1), and PcGive (10.4), but three different
> sets of standard errors:

[estimates follow]

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?

Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti

--===============0175630777029392229==--