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 [...]

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.

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?

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.

OK, this is frankly silly but here's an extension of usenet-inspired acronyms (well, really just abbreviations) that I sometimes use in my own mind for certain modifications to gretl: BM: bloody marvellous BFM: (superlative) you can probably guess but, TCBH: Too clever by half (Anglicism, meaning an over-reach, something that is apparently clever but actually messes things up; the sort of thing that Sven reasonably inveighs against)