On Tue, 1 Mar 2016, Riccardo (Jack) Lucchetti wrote:
On Tue, 1 Mar 2016, Allin Cottrell wrote:
> The motivation for recording "t1" and "t2" (starting and ending
> observations) on matrices derived from series was to do with issues that
> come up in time-series work (i.e. allowing for lags/leads, differences,
> etc.). The notion was that if you sucked a matrix out of a series at one
> point, then it might be useful to know where it (or a transformation of it
> that preserved the number of rows) should be stuck back into the dataset at
> a later point.
>
> Having t1 and t2 saved on a matrix also allows "series s = matrix m" for
> cases where the the length of m is not equal to the current sample range
> nor the full length of the dataset, provided the t1 and t2 values are in
> range.
Agreed. But this information is something that the user can easily store
somewhere else (eg two scalars) if needed. I would guess that anybody who
needs to pour a matrix into a series or vice versa in a non-trivial way can
be considered savvy enough to handle "row accounting" by themselves.
Fair point. I've now remembered a bit more about this. The original
deal with setting t1 and t2 on matrices just applied to matrices
generated by gretl itself.
Use case: you've estimated a time-series model on thousands of daily
data-points and you want an out-of-sample forecast for a few tens of
observations; gretl provides a forecast matrix for that
out-of-sample period. Now you want to convert/add the values in the
matrix to the dataset. If we didn't have t1 and t2 recorded we
couldn't do it, and the alternative would be to have a BIG matrix
that matched the dataset length and was 99% NaNs.
I guess the controversial (or most controversial) thing here is
extending this idea to user-created matrices, where (I admit) it may
in some cases defeat the user's purposes or mask an error in the
user's logic.
Allin