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