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