Re: [Gretl-devel] args in lags() vs. mlag()
On Tue, 14 Mar 2017, Allin Cottrell wrote:
On Tue, 14 Mar 2017, Riccardo (Jack) Lucchetti wrote:
> On Tue, 14 Mar 2017, Allin Cottrell wrote:
>>
>> 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.
That's now in git, and documented.
One point to note: mlag() orders the columns in the output matrix
(in case the input matrix has more than one column and more than one
lag is specified) "by lag" by default (and without an option). But
if you supply a matrix argument to lags() and want the "by lag"
ordering you'll have to give a non-zero value for the optional third
argument, as stated in the help for lags().
That is, lags() with a matrix argument in the second slot (the newly
supported possibility) works as similarly as possible to lags() with
a list argument in that slot.
Allin