3:04 a.m.
I've recently been working on a gretl function to implement the
panel unit-root test of Breuer, McNown and Wallace (Oxford
Bulletin of Economics and Statistics, 2002), which takes into
account cross-equation correlations while allowing for
the testing of the unit-root null on a per-group basis.
In that context I realized that -- unless I'm missing something --
we didn't have a means of constructing a "system" spec on the fly
(when the number and make-up of the equations is not known until
run-time). Possibly one could do domething cunning but ugly with
strings, but I couldn't see any other way.
So in CVS I've implemented a generalization of the system spec.
I'm not sure that my approach is the best one: it has the virtue
of causing the least disruption to existing gretl types and
command structures, but has some limitations. So I'd like to
invite comments.
Here's the deal: Up till now the only thing accepted by way of
specification of the equations in a "system" block has been a set
of "equation" statements, but now you can say
equations <matrix-name>
Note the plural in "equations". The parameter should be the name
of a pre-defined matrix, each row of which represents a list
(left-hand side variable, regressors). If some lists are longer
than others, the matrix should have g columns where g is the
length of the longest list, and shorter lists should be padded
with trailing zeros.
It works, but has a couple of limitations:
(1) Since trailing zeros are ignored, you can't place the constant
at the end of an equation list. This shouldn't be a real problem,
since you are better placing the constant first; it will be
shuffled into first place by gretl anyway.
(2) You can't insert the equivalent of ";" into a matrix, and so
you cannot specify an equation's list "tsls-style". This is a
problem only (a) if you are using instruments and (b) you want to
use specific instruments in specific equations rather than using a
common set of instruments for all equations.
Here's a simple example (it's not complete, and presumes some
"stage-setting", but might convey the idea):
scalar g = <whatever>
scalar listmax = <whatever>
matrix surrow
matrix surmat = zeros(g, listmax)
loop i=1..g
# build g lists and insert into matrix surmat
p = laglengths[i]
list eqlist = xd$i const x$i(-1) xd$i(-1 to p)
matrix surrow = eqlist
k = nelem(eqlist)
if (k < listmax)
# this equation is "short"
surrow ~= zeros(listmax - k)
endif
surmat[i,] = surrow
endloop
system method=SUR
equations surmat
end system
Allin
1:47 p.m.
Needless to say, it's a welcome extension of gretl's capabilities. Here
are some comments and questions...
Am 10.12.2010 04:04, schrieb Allin Cottrell:
...
Here's the deal: Up till now the only thing accepted by way of
specification of the equations in a "system" block has been a set
of "equation" statements, but now you can say
equations <matrix-name>
Note the plural in "equations". The parameter should be the name
of a pre-defined matrix, each row of which represents a list
(left-hand side variable, regressors). If some lists are longer
than others, the matrix should have g columns where g is the
length of the longest list, and shorter lists should be padded
with trailing zeros.
First a general question: Is it planned (in the longer term) to add
nonlinear system estimation to gretl? (Apart from generic GMM I mean.)
If so, then maybe this should be borne in mind when choosing the design
now.
(I might add that I don't think that nonlinear system estimation is a
terribly important feature. OTOH, right now I am working on a paper
where we use nonlinear three-stage LS and I'm forced to not use gretl
because of that. I'm not complaining, but it's a fact.)
It works, but has a couple of limitations:
(2) You can't insert the equivalent of ";" into a
matrix, and so
you cannot specify an equation's list "tsls-style". This is a
problem only (a) if you are using instruments and (b) you want to
use specific instruments in specific equations rather than using a
common set of instruments for all equations.
Is it the case that the matrix contains the ID numbers of the variables?
Then in principle I guess that negative numbers could be used as codes
for stuff like ";". But wouldn't it in general be a better idea to use
the new bundle data type for these things? Let's say a bundle which
describes a system must be composed of g sub-bundles (where g is the
number of equations), and each sub-bundle consists of one series
(left-hand side variable), one list of regressors, and one optional list
of instruments. Or something like that.
With respect to the nonlinearity concern from above, one could in
principle imagine that in some distant future each of the g sub-bundles
receives an extra (also optional) argument which would represent the
description of the functional form with which the referenced list
members are connected.
cheers,
sven
2:36 a.m.
On Sat, 11 Dec 2010, Sven Schreiber wrote:
Needless to say, it's a welcome extension of gretl's
capabilities. Here
are some comments and questions...
Am 10.12.2010 04:04, schrieb Allin Cottrell:
>
> Here's the deal: Up till now the only thing accepted by way of
> specification of the equations in a "system" block has been a set
> of "equation" statements, but now you can say
>
> equations <matrix-name>
>
> Note the plural in "equations". The parameter should be the name
> of a pre-defined matrix, each row of which represents a list
> (left-hand side variable, regressors). If some lists are longer
> than others, the matrix should have g columns where g is the
> length of the longest list, and shorter lists should be padded
> with trailing zeros.
First a general question: Is it planned (in the longer term) to add
nonlinear system estimation to gretl? (Apart from generic GMM I mean.)
It's not on the active list at present, but may happen at some
point.
> It works, but has a couple of limitations:
> (2) You can't insert the equivalent of ";" into a matrix, and so
> you cannot specify an equation's list "tsls-style". This is a
> problem only (a) if you are using instruments and (b) you want to
> use specific instruments in specific equations rather than using a
> common set of instruments for all equations.
Is it the case that the matrix contains the ID numbers of the
variables? Then in principle I guess that negative numbers could
be used as codes for stuff like ";".
True, but this would be very ugly.
But wouldn't it in general be a better idea to use the new
bundle data type for these things? ...
That's an interesting suggestion, thanks. It could support various
possible future extensions -- including nonlinear specs, as you
say.
Allin
5130
days inactive
5132
days old
2 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber