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().