This is sort of a companion piece to
http://lists.wfu.edu/pipermail/gretl-devel/2018-June/008842.html
The filter() function is certainly nice to have, but I can't help
thinking it's kinda backwards, and hence less intuitive than it could
be -- or is it just me? This function offers "an ARMA-like filtering
of the argument x", but what's naturally interpreted as the MA part
comes first and is obligatory while the AR part is second and
optional. You can of course use it to construct a pure AR series but
that requires "pretending" that y is x, so to speak. Here's a little
example, comparing "by hand" calculation with filter() and a notional
armafilt() function that puts the AR term first.
<hansl>
# "by formula"
de_c = -1 - m * de_c(-1)
de_a = -y(-1) - m * de_a(-1)
de_m = -e(-1) - m * de_m(-1)
# via filter()
de_c = -1 + filter(de_c, -m)
de_a = filter(y, {0,-1}, -m)
de_m = filter(e, {0,-1}, -m)
# perhaps preferable?
de_c = -1 + armafilt(-m)
de_a = armafilt(-m, y, {0,-1})
de_m = armafilt(-m, e, {0,-1})
</hansl>
Note that with filter() on the first equation one has to enter "y"
(meaning the series on the left) in the argument slot that's labeled
"x" in the documentation. This works OK, but somehow it's not so
obvious that it's going to work.
To be explicit, my notional armafilt() would have one required
argument, a scalar AR coeff or vector of same. Then would come an
optional series for MA treatment and a scalar MA coeff or vector.
To get a pure MA you'd give 0 as the first argument.
Allin