Re: [Gretl-devel] constructing an SUR system programmatically
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