Am 15.03.2017 um 14:03 schrieb Allin Cottrell:
On Tue, 14 Mar 2017, Allin Cottrell wrote:
> One point to note: mlag() orders the columns in the output matrix
> 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().
Do we really like this?
If I understand correctly, no we (=I) don't, as I was asking for:
lags(p, M) equivalent to mlag(M, seq(1,p))
which doesn't seem to be the case.
OTOH, it's not clear why that strict equivalence is really needed...
I have to admit I'm not so sure. A matrix is a more
than a list of series, and I think the behavior of mlag() makes better
sense as the default. That is, if you specify two or more lags you get
the horizontal concatenation of lag 1 of the whole matrix, lag 2 of the
matrix, and so on ("by lag").
But why, actually? Once you have the semantics of a "lag", it's clear
that the matrix is just a collection of columns, not a unitary block.
We _could_ make the default for the optional 3rd argument to lags()
differ by the type of the second argument, but as I've said I think
I agree, that's messy.
-- we can stay with what we now have in git!
Yes, I think that's fine. So if you just need the lags as control
regressors (projection) in an mols() for example, you can now do
lags(p,M) just like you would have used lags(p,L) with the OLS command.
If you need only certain lags or a different ordering, one can use
mlag() (or perhaps lags(p,M,1)). Problem, solved.
(BTW, wouldn't it be nice to have a $true accessor that one could use in
lieu of a boolean 1 in hansl? And perhaps $false as well... Would make
some code easier to read.)