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
for coint2 and var/vecm the "--seasonal" option is deprecated I think
but still tolerated.
In the guide, however, it still appears twice, in sections 30.3 and 30.4.
(When will I ever become comfortable with git, this would be an easy
I'm pleased to announce that our code for exact ML estimation of
ARMA models is now (in git and snapshots) MUCH faster than it used
to be (like, two orders of magnitude faster in many cases).
This is due to two main factors. First, we now use by default G.
Melard's algorithm AS 197 (Applied Statistics, 1984). This employs a
very compact recursion similar to but distinct from the Kalman
filter. Second, Jack developed an elegant means of "flipping" an MA
polynomial that has roots inside the unit circle: this means that
our Hannan-Rissanen initializer should never be unusable, and also
that BFGS has less work to do. (We never have to tell it, "You're
out of bounds, try again.")
One qualification: we can't use AS 197 when there are missing values
within the sample range; computing the MLE in that case requires the
Kalman filter. However, our first resort is now the Kalman algorithm
AS 154 (Gardner, Harvey and Phillips, 1980). This is not as fast as
AS 197 but, being specialized for ARMA, it's still a good deal
faster than using our general-purpose Kalman code. The most
difficult case is ARIMA (i.e. with differencing) in the presence of
missing values: that demands an extended state-space representation
incorporating levels, for which we fall back on our original Kalman
At present there are two "secret" (undocumented) options for the
arma/arima command, which we've used for testing. We could document
these and make them generally available but I'm not sure that would
be worthwhile. Anyway, in case anyone wishes to do some testing,
here they are:
First, there's an option to force use of AS 154 when AS 197 would be
used by default:
arma ... --as=154
Second, there's an option to use our original Kalman code when AS
197 or AS 154 would be used by default:
arma ... --kalman
To summarize, the default algorithm is AS 197 unless there are
missing values, in which case we use AS 154 if the specification is
plain ARMA or our full Kalman code if it's ARIMA.
Thanks go to Oleh for pushing us in this direction!
this is not urgent, but before I forget (sorry, don't have time to
re-read the doc right now, perhaps the answer is already in there): When
building under Windows (mingw/msys) I cannot build the addons, because
the configure script doesn't find pdflatex.
Can I point to the existing pdflatex from the Miktex distribution or do
I have to install an extra Tex distribution inside mingw?
I'm trying to put together a package, and the corresponding entry in the
gfn file correctly says:
This referenced file exists. But when I test the package, the "info"
window (after right-clicking on the package in the package chooser
window) has the wrong reference "CSD_panel.pdf". Consequently the pdf
help cannot be launched.
Apparently somewhere it's hardwired that the pdf help file has the same
name as the package, only a different extension?
I think it would be useful if gnuplot's capability to put several plots
next to each other could be offered to the gretl user. What comes to
mind is the 'plot ... end plot' block.
What I mean is to introduce a further 'subplot' nested block such that
the following block would produce the same thing as the (already
currently working, at least for me) hansl code at the end.
Would that be too difficult to arrange?
option multiplot-layout=2,1 # or similar
option time-series # would apply to all subplots
# room for specific options
# room for specific options
end plot --output="display"
# produce the subplots
gnuplot LRM --time-series --output="p1.plt"
gnuplot LRY --time-series --output="p2.plt"
string s1 = readfile("p1.plt")
string s2 = readfile("p2.plt")
# prepare the combination commands
outfile multi.plt --write
print "set multiplot layout 2,1 columnsfirst"
printf "%s\n%s\n", s1, s2
print "unset multiplot"
# execute and display
gnuplot --input="@workdir\multi.plt" --output="display"
shouldn't this work:
series d = $unit
list a = dummify(d) # works
list b = dummify($unit) # fails, datatype mismatch
I guess the problem is that dummify needs a series name for the labels
of the dummies? But still...
set verbose off
set seed 123456
foo = randgen(N, 10, 2)
freq foo --nbins=3
freq foo --nbins=4
Why I get 5 bins instead of 4 in the second freq call?
[moving this to the devel list]
Am 13.04.2018 um 21:50 schrieb Sven Schreiber:
> Am 13.04.2018 um 18:24 schrieb Sven Schreiber:
>> I'm wondering how to achieve something that would be the multivariate
>> generalization of the lrvar function (long-run variance of a series).
> Duh, dummy me -- it's in my own package CommonTrendsTest.
I'm reproducing the two private functions autocovar() and longrunvar()
from the package below. The question is whether it might make sense to
add these to the extra package, or whether it could be considered to
generalize the built-in lrvar() to multivariate (like it seems to be the
case in R, for example).
What do you think?
(I'm also open for suggestions to increase efficiency, but that's not
very pressing right now. I think I read about fast algorithms that use
the FFT for example.)
function matrix autocovar (const matrix indatamat,
/* Computes the autocovariance at lag "lag"
for a multivariate time series.
Returns a NxN covariance matrix
# N = cols(indatamat)
T = rows(indatamat)
matrix datademeaned = demeaned ? indatamat : cdemean(indatamat)
matrix result = datademeaned[lag+1 : T,]'datademeaned[1 : T-lag,]
result /= T
/* should hopefully be equivalent to the following loop code:
matrix result = zeros(N,N)
loop for tindex=lag..T
matrix dev1 = datademeaned[tindex,]
matrix dev2 = datademeaned[tindex-lag,]
matrix result += dev1'dev2
matrix result /= T
function matrix longrunvar (const matrix indatamat,
/* indatamat is a TxN time series matrix
returns an NxN matrix (spectral density at frequency zero)
N = cols(indatamat)
matrix result = zeros(N,N)
loop tau = 1..lagtrunc -q
matrix Gamma = autocovar(indatamat, tau, demeaned)
# positive and negative tau range together:
result += (1 - tau / (lagtrunc + 1)) * (Gamma + Gamma')
# add the tau=0 part:
result += autocovar(indatamat, 0, demeaned)