Re: [Gretl-users] convert matrix to series
On Tue, 1 Mar 2016, Riccardo (Jack) Lucchetti wrote:
On Tue, 1 Mar 2016, Sven Schreiber wrote:
> Am 01.03.2016 um 20:14 schrieb Allin Cottrell:
>> On Tue, 1 Mar 2016, Sven Schreiber wrote:
>>
>>> Am 01.03.2016 um 19:44 schrieb Pedro Bação:
>>>> Hello,
>>>> If I run the script
>>>>
>>>> nulldata 10
>>>> smpl 6 10
>>>> series y=t
>>>> matrix my=y
>>>
>>> I cannot explain why exactly you are getting the results you are
>>> getting with the different gretl versions [...]
>>
>> The old version did not record and make use of the observation
>> information when matrix (column vector) "my" was created. The new
>> version does, so when you go to make a series out of "my", gretl
"knows"
>> that it contains no data corresponding to observations 1 to 5.
>>
>
> Hm, I'm not sure I like it. I mean in principle it is very clever, but OTOH
> up to now the clear distinction between series and matrices in gretl was
> that that latter is just pure numbers (well, sometimes with column and row
> names, ok).
>
> I admit that sometimes I wish I could use matrices in gretl commands just
> like series, and there are problems with the division between series and
> matrices, but that's a pretty fundamental design decision. It kind of feels
> like R-dataframe-envy or something like that :-)
>
> And as Pedro demonstrated, trying to be clever does come with side effects.
I'm with Sven on this. It's ok to decorate matrices with row and column
names, but IMO the contents of a matrix should be completely independent from
the currently open dataset.
I can't remember when the feature Allin describes was introduced, nor why.
Perhaps I'm missing something here?
I too take Sven's point here. I too was a bit surprised when this
popped up in the context of an undated dataset.
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.
I'll have to check how much, if anything, would be disturbed if we
abolished this behavior. But a half-way house would be:
(a) record t1 and t2 on series-derived matrices only when the
dataset is time-series; and
(b) use this information when converting back from matrix to series
only if the number of rows in the matrix fails to match the current
sample size or the length of the dataset. Hence it could only avert
an error that would othwerise occur in the conversion -- though I'm
aware that it could mask a real error under some conditions.
Allin