Hi Artur,
thanks for your girf work!
Artur T. schrieb:
> Hi all,
>
> I found some time to improve my gretl programming skills a little bit
> and improved the function for the GIRF. I've got still some issues with
> it. Maybe somebody is interested to help me with it...
>
> 1. The results seem to be ok from my perspective. Since I cannot compare
> them at the moment, maybe someone is interested in checking the code.
sorry, don't have the time currently to do a cross-check
In general I would think about splitting the function in at least two
parts:
one, say getGIRF(), which does the computations and returns a matrix of
the girfs (ok, probably actually a matrix of stacked girfs since we have
three dimensions here: shock, target, horizon).
And another one, say plotGIRF() which takes the matrix from getGIRF(),
plots it somehow, and doesn't return anything (same as your function).
That way you or somebody else can reuse getGIRF() in other applications
where you may want to do something more with the GIRFS (check the signs
in a script, bootstrap, or whatever).
>
> 2. I would like to add an output describing which is the shock variable
> and which are the responses for the generated matrix. Something like:
>
> Responses of the respective variables to a shock in Variable 1.
> Period Variable 1 Variable 2 ...
> 1 0.03 0.9
Something like this?:
numofvars = nelem(Y)
loop for i=1..numofvars # loop over shock origins
printf "Responses of the respective variables \
to a shock in Variable %d\n", i
printf "Period "
loop for j=1..numofvars
printf "Variable %d ", j
endloop
printf "\n"
loop for j=1..horizon
printf "%d ", j
loop for k=1..numofvars # loop over target vars
printf " %f ", girfmatrix[i, k*j]
# (girfmatrix defined elsewhere)
# (and number of blanks needs adjustment)
endloop # target loop
printf "\n"
endloop # horizon loop
printf "\n"
endloop # origin loop
>
> 2. I wrote the function in such a way that it estimates a VAR system and
> then conducts the GIRF. Since you can have all those additional options
> like --nc --trend --robust and so on, the function would be quite big to
> consider all those cases. So, is it maybe reasonable to call the
> function after one has estimated the VAR by the conventional way and
> then calling the function?
Not for turning it into a function package at some point, I'd say.
Adding the various options later is easy, and the extra code is
straightforward. So IMHO it won't be a problem if it will be a bit lengthy.
>
> 3. I also would like to improve the plotting. I want to plot the
> responses of all variables to a specific shock within one graph. For
> example, if I have three variables which are shocked, the plot command
> must be "gnuplot 1 2 3 --time-series..." where 1 2 3 denote the
> corresponding columns of the response matrix. Is there a way to
> generalize this in such a way that one can type in the corresponding
> numbers of coulumns one wants to plot in the "function-gui" or just to
> plot all columns which equals the number of endogenous variables?
There are many combinations and thus I don't think it makes much sense
to make it a GUI option. I haven't checked thoroughly, but I'm not aware
of a way to construct the gnuplot command where the number of columns is
unknown at coding time. (Apart from having many if-blocks and separate
gnuplot commands for all cases, of course.) Maybe the gnuplot command in
gretl could be extended with a syntax to plot *all* columns of a matrix?
cheers,
sven
