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