7:03 a.m.
Hi,
I find it confusing in routine work that the lags() function wants to
have the lag number as the first arg, while the mlag() function wants to
have the input matrix first and afterwards the lag number.
Don't know how, maybe this could be aligned somehow in the future.
cheers,
sven
6:46 a.m.
Am 17.02.2017 um 13:03 schrieb Sven Schreiber:
I find it confusing in routine work that the lags() function wants
to
have the lag number as the first arg, while the mlag() function wants to
have the input matrix first and afterwards the lag number.
ping, stumbled over this again... but maybe it's just me.
-sven
9:44 a.m.
On Tue, 14 Mar 2017, Sven Schreiber wrote:
Am 17.02.2017 um 13:03 schrieb Sven Schreiber:
> I find it confusing in routine work that the lags() function wants to
> have the lag number as the first arg, while the mlag() function wants to
> have the input matrix first and afterwards the lag number.
ping, stumbled over this again... but maybe it's just me.
I agree. If we had this to do over we'd try harder to do it
consistently. But isn't it now too late?
Allin
10:10 a.m.
Am 14.03.2017 um 14:44 schrieb Allin Cottrell:
> Am 17.02.2017 um 13:03 schrieb Sven Schreiber:
>
>> I find it confusing in routine work that the lags() function wants to
>> have the lag number as the first arg, while the mlag() function wants to
>> have the input matrix first and afterwards the lag number.
>
> ping, stumbled over this again... but maybe it's just me.
I agree. If we had this to do over we'd try harder to do it
consistently. But isn't it now too late?
Yes, perhaps. OTOH, there is of course another difference between lags()
and mlag() which is already apparent from the names, namely that the
former gives you all lags up to p, whereas the latter gives you just one
lag (if you feed it a scalar lag arg).
So, one possible solution might be to introduce a new mlags() function
(note the plural-s) which would satisfy:
mlags(p, M) equivalent to mlag(M, seq(1,p))
mlags(p, M) analagous to lags(p, L)
Writing this down, another thing occurs to me: Couldn't lags() just be
overloaded, such that for a matrix argument M:
lags(p, M) equivalent to mlag(M, seq(1,p))
cheers,
sven
12:50 p.m.
On Tue, 14 Mar 2017, Sven Schreiber wrote:
Am 14.03.2017 um 14:44 schrieb Allin Cottrell:
>> Am 17.02.2017 um 13:03 schrieb Sven Schreiber:
>>
>>> I find it confusing in routine work that the lags() function wants to
>>> have the lag number as the first arg, while the mlag() function wants to
>>> have the input matrix first and afterwards the lag number.
>>
>> ping, stumbled over this again... but maybe it's just me.
>
> I agree. If we had this to do over we'd try harder to do it
> consistently. But isn't it now too late?
Yes, perhaps. OTOH, there is of course another difference between lags() and
mlag() which is already apparent from the names, namely that the former gives
you all lags up to p, whereas the latter gives you just one lag (if you feed
it a scalar lag arg).
So, one possible solution might be to introduce a new mlags() function (note
the plural-s) which would satisfy:
mlags(p, M) equivalent to mlag(M, seq(1,p))
mlags(p, M) analagous to lags(p, L)
No, please, let's not overpopulate the namespace.
Writing this down, another thing occurs to me: 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!
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
4:38 p.m.
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?
Allin
5:05 p.m.
Am 14.03.2017 um 21:38 schrieb Allin Cottrell:
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 don't know, perhaps nothing? But keeping the ways of mlag() might also
be good -- what exactly is the use case for the non-zero fill value for
the missings? To put in an average of some sort?
cheers,
sven
5:16 p.m.
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.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
5:26 p.m.
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
10:25 p.m.
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
9:03 a.m.
On Tue, 14 Mar 2017, Allin Cottrell wrote:
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().
Do we really like this?
I have to admit I'm not so sure. A matrix is a more "unitary" object
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").
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
that's messy. Or I could back out my changes and revert lags() to
handle only series or list input. Or -- if nobody shares my qualms
about this -- we can stay with what we now have in git!
Allin
9:48 a.m.
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
(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().
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
"unitary" object
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
that's messy.
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.)
thanks,
sven
2764
days inactive
2790
days old
11 comments
3 participants
participants (3)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti -
Sven Schreiber