Here's an update in relation to the thread (re-)started by Sven at
We now have irf() and fevd() functions which go part-way to meeting
Sven's suggestions. We could go all the way if we reckon it's
worthwhile (see below). Anyway, at present:
arg1 target [required]
arg2 shock [required]
arg3 alpha [optional]
arg4 bundle [optional, obtain via $system]
Returns: matrix containing response of targ to shock, optionally
with bootstrap confidence interval.
arg1 target [required]
arg2 bundle [optional, obtain via $system]
Returns: matrix containing full decomposition of forecast variance
The final, optional, bundle argument should be obtained via the
$system accessor (which still has to be documented) after estimation
of a VAR or VECM. If this argument is omitted gretl looks to the
last estimated model to get the equivalent information; if there's
no such model or it's not a VAR/VECM an error is flagged.
The divergence from Sven's specific suggestions reflects some
(debatable) simplification on my part.
It seems to me that when a FEVD is wanted, most of the time you'd
want it for a single "target" variable and all sources of variation.
So right now you must choose a target and do not get to choose a
single source. You can of course pull a specific column of interest
out of the returned matrix if you want less information, or call the
function in a loop if you want more.
In the (more expensive) IRF case, however, it seems to me that the
response of a single target to a single shock (with or without a
confidence interval) would be the most "natural" unit. So you have
to specify both target and shock.
Possible modifications: We could add a "source" argument to fevd()
to narrow the output, and for the target/shock arguments to both
functions we could let 0 signify "do everything".
I'm trying to stuff a list of series into a bundle (allowed since 2017b)
that will be the container (result collection) of a function package.
The purpose is to hand over to the package user this set of series, so
that they can be saved (from the package output window).
The window appears OK, and I can select the included list from the
bundle icon / drop-down menu. I am asked to enter a list name, and I do
Then, however, nothing seems to happen. No new variables appear in
gretl's main window, and the list is not to be found when I select
create/edit lists from the menus. The same thing if I open the bundle
from the session symbol view and proceed from there.
I know that lists are tricky, and lists in bundles even trickier. Is
this out of the feature scope or a bug?
I just saw that there is a "mailing lists" tab on the sourceforge
interface, and it contains something about gretl-devel and gretl-users.
However, these are totally different things than our lists.
I propose to just delete/remove them (if possible, still have to find
there's something that shows up (again, at least for me) when updating
the yahoo_get package. I had the previous version 1.21 locally
installed. Now I've downloaded (from within gretl) the new version 2.0.
(This is on Win 7.) In the package list window I now have two entries
Then I try to delete the older version by right-clicking and choosing
unload/delete. After several seconds I get a gretl "information" window:
"Package yahoo_get is not loaded".
I think this is not specific to the yahoo_get package.
as a result of discussing the gnuplot integration with the Lyx people,
the gnuplot readme w.r.t. Windows came up:
"* gnuplot.exe: Text (console) mode version of the gnuplot executable
with full pipe functionality as it is common on other platforms. In
contrast to wgnuplot.exe, this program can also accept commands on stdin
(standard input) and print messages on stdout (standard output). It
replaces pgnuplot.exe and is recommended to be used with 3rd party
applications using gnuplot as graph engine, like e.g. Octave
Despite gnuplot's recommendation, gretl seems to use wgnuplot.exe. Why?
the new multivariate long-run covariance function lrcovar is in gretl
and working, but it isn't mentioned in the changelog nor does the
function appear in the reference.
Were there any open questions that we still wanted to settle before
making this official?
the irf() function is a weird thing in the sense that it is the only (?)
function that requires input beyond its specified arguments. Namely the
information from the previous VAR/VECM estimation. From a
programming-language systematic point of view it seems to be the "odd
In contrast, the analogous FEVD calculations are not wrapped in a
function, but in the $fevd accessor, which makes more sense IMO.
So I suggest to introduce a matching $irf accessor with the same layout
as the $fevd accessor. I am aware that the irf() function also needs an
alpha input; this could be done via "set irf_alpha 0.1" or something
Alternatively, the irf() function could get a new bundle argument which
would collect the VAR/VECM results. That way, no dependency on
non-argument input would be required, making the use consistent with all
the mailing lists are quite quiet - not sure whether that's good or bad
(topic for a different thread), but in any case maybe that's a good time
to fix one or two issues from the trackers.
Number 195 (https://sourceforge.net/p/gretl/bugs/195/) seems fairly
easy, essentially all that's left is "1) Baltagi/Li for the unbalanced
case should still be mentioned,".
From the feature requests I don't have a favorite (although some of
them are mine...).
I know the previous release isn't that old yet, but we had some crash
fixes (at least on Windows), and considering the delay in preparing the
release, I really think it would be good if we had another one before
the summer break.