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="===============1835229553406615532=="

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

--===============1835229553406615532==--


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="===============6930965621825232249=="

--===============6930965621825232249==
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

--===============6930965621825232249==--


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="===============4910504112016602203=="

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

--===============4910504112016602203==--