Re: [Gretl-devel] args in lags() vs. mlag()
On Tue, 14 Mar 2017, Riccardo (Jack) Lucchetti wrote:
On Tue, 14 Mar 2017, Allin Cottrell wrote:
> On Tue, 14 Mar 2017, Riccardo (Jack) Lucchetti wrote:
>
>> On Tue, 14 Mar 2017, Sven Schreiber wrote:
>>
>>> Couldn't lags() just be overloaded, such that for a matrix argument M:
>>> lags(p, M) equivalent to mlag(M, seq(1,p))
>>
>> Now, THIS I like!
>
> There's now a "mock-up" of this in git.
>
> A question remains: what becomes of the optional third argument to lags()?
> In the series (or list) version, that option lets you arrange the output
> "by lag" rather than "by variable", while in mlag() the extra
argument lets
> you specify a value other than zero for the missing elements. What should
> it do in the matrix-arg variant of lags?
I think we should go for the former option. Not only it's more useful IMO,
iot also provides consistencly across the possible uses of the lags()
function. In practice, we'd be merely extending the function by allowing for
a matrix argument.
I think I like that best: among other things it minimizes the amount
of extra explanation required in the doc for lags(). Overloading is
OK, and quite common in gretl functions, but overloading that alters
the semantics of (or invalidates) other arguments is kinda messy.
BTW, on the usefulness or otherwise of the final argument to mlag:
my thought was that in some contexts it's standard to set pre-sample
lags to zero but in other contexts you might want to set them to a
clearly invalid value, e.g. 0/0 = NaN.
Allin