10:44 a.m.
Am 24.04.2016 um 16:12 schrieb Andreas Zervas:
I was wondering whether it would be possible to add some features in
Gretl that some of us will find extremely useful (provided I guess it is
not such a big burden to code them).
That's a lot of different features, maybe it would help if you named
some priorities. Apart from that, feel free to create items/tickets on
the Sourceforge feature request tracker for gretl so that these things
are not forgotten.
The first is related to systems: I was wondering whether it would be
possible to add the ability to include identities in systems estimated
with estimators other than FILM; it would be very useful to have such an
ability for forecasting / simulation purposes, even if estimation is not
fully efficient; in any case OLS / IV estimation of systems should give
more robust results.
This is actually directly connected to your next point, because as you
say identities for OLS/IV etc. are only needed for forecasting or
simulation, not for estimation.
Answer: Truly, they are connected. But I think mimicking model structure in EViews should
be much more demanding with respect to coding, while adding identities in systems seems to
me that it only extends a capability already present in the FIML estimator. But off course
the programmers know better.
A related extension would be to develop a framework to imitate the
EViews model functionality: add single (estimated or not) equations or
systems of equations to a bigger model and simulate this structure. I
understand that this is much more complex from a computational and
programming point of view than the previous suggestion.
Yes I suggested something like this to Allin and Jack myself some time
ago. There has been some underlying work in gretl's foundations to make
this feasible at some point at the level of Hansl programming/scripting.
(For example making more use of the 'bundle' collection datatype.)
However, there is only so much that Allin and Jack can do.
Note that if forecasting or simulation is done in an extra function
package then the specification of identities would not be necessary in
gretl's 'system' estimation command. Instead you would provide the
information about the identitites in the system to the extended
forecasting package, and that package (not yet existing...) might
internally call gretl's system estimation. Of course, it's all a
question about the user interface of that package / add-on.
Perhaps you could start with systems having recursive structure so as to
initially avoid the problem of finding the solution satisfying all
equations in all periods.
Maybe.
A third very useful feature in my opinion relates to graphs: it is very
useful to have subplots in the same graph, as in matlab / octave.
graphpg is a substitute with limitations, not least in the number the
way you put the subplots.
You mean whether it's 2-by-4 or 4-by-2 for example?
Answer: or 3-by-3 etc... The 2 by 4 limit seems to me like a logical, yet arbitrary limit
that assumes a A4 page with portrait orientation. Gretl itself allows more subplots
(4-by-4 I think) in the case of its native SVAR IRF plotting implementation using the
GUI.
Secondary graph request: is it possible to allow for other
linestyles
like the usual dashes, dots etc in Gretl without editing gnuplot files?
This feature is approaching, there has been some discussion already (on
the devel list I think). It depends on the underlying gnuplot version.
Answer: Very nice - eager to see it.
Finally (to Riccardo only) : please, when it is possible add some
remaining functionalities to SVAR package. First, there is no reason
(and should not be very difficult) to have AB models for VECMs (as
eventually these are also VARs).
Happy to hear that there's demand for the SVAR package. Your request is
fair enough, but at least this variant is not very common I think.
Personally I'm not a big fan of AB models, because I never saw a
convincing case where you absolutely had to distribute your
contemporaneous restrictions over two matrices.
Answer: I work in fiscal policy issues - there the workhorse is the Blanchard - Perotti
(2002) identification restrictions, that correspond to an AB model. You can do it with IV
estimation, but it is useful to have the structural factorization. Nevertheless, in
general you are right.
Secondly, please try to add long run
restrictions on permanent shocks. Essentially, would it be possible
to
allow more general identification restrictions like in Jmulti or Warne's
SVAR?
Assuming we're talking about the permanent shocks in a cointegrated SVEC
model, yes there were some issues to be resolved about long-run
restrictions if I remember correctly. I think Jack had a preliminary
paper about something related. This is work-in-progress in principle,
but I will openly admit that progress isn't very quick there.
Answer: Ok, yet it will be great help when it is available.
A related thing is that it would be nice to have a function to
simply
estimate the structural factorization. I think that the necessary
ingredients to do that is the variance covariance matrix form the VAR /
VECM and a pattern matrix holding restrictions and free elements; could
you have a public function to do just that, or how is it possible to do
that in the current state of the SVAR package? I tried to do it myself
that but the code is so complicated that I gave it up.
Here I don't quite understand what you mean. Once you estimate the SVAR,
you always get the estimated A or B or C. What else do you mean?
Answer: Think of a Bayesian VAR with a natural conjugate prior - IRFs etc come from
simulation. Starting from a draw of the variance covariance matrix of residuals, the only
feasible SVAR is one using a Cholesky decomposition. But having a public function to
estimate the contemporaneous matrices without needing the full VAR estimation would make
it possible to do this kind of analysis.
Thank you for all the good stuff you have given us so far. I hope these
are not too much to ask.
It all depends on your time-frame and patience ;-)
cheers,
sven
Hope I made myself clearer.
Thank you all,
Andreas