Re: [Gretl-devel] matrix to list conversion
On Sun, 11 Jan 2015, Sven Schreiber wrote:
Am 11.01.2015 um 14:09 schrieb Riccardo (Jack) Lucchetti:
> On Sun, 11 Jan 2015, Sven Schreiber wrote:
>>
>> For the direction list-to-matrix we have the wonderful {} syntax, and
>> section 15.9 describes how to do matrix-to-series. So why not
>> matrix-to-list?
>
> Well, a problem I see with is that list elements are series you ought to
> give a name to. I guess you could call the X1, X2 and so forth, or
> otherwise you could supply a second "strings" argument.
Yes you're right, and my example code would therefore not work as-is. As
you say, one could have an optional string argument, or if the matrix
has column names, those could be used, or as a fall-back one could use
the supplied list name with appended numbers 1 to n.
Like Jack, I'm a bit skeptical about adding this as a built-in, partly
because I suspect it should be up to the user to decide how to name
the resulting series. However, it can be done quite efficiently via a
user-defined function, particular after I've fixed a little issue with
genseries():
<hansl>
function list mat2list (matrix *m)
mname = argname(m) # or whatever you like
list L
loop i=1..cols(m)
L += genseries(sprintf("%s%d", mname, i), m[,i])
endloop
return L
end function
nulldata 20
matrix mymat = mnormal($nobs,3)
list L = mat2list(&mymat)
print L --byobs
</hansl>
My impression from [Jack's] code that I have seen is that you
quickly go the all-matrix route. That is fine of course but my
interpretation is that it's exactly because of the list limitations.
I would bet that that is also the reason why somebody (you?)
invented the mols() and related matrix-only functions, which are
essentially a duplication of existing functionality. So it looks
like that was your way of solving similar problems. I'm not sure
that this duplication solution is optimal, but of course one can
argue about that.
OK, let's do so ;-) IMO, while working with a dataset, series and
lists is often very convenient, it's also important for gretl to
support a reasonably full-featured matrix approach -- we want, for
example, for people to be able to translate R or Matlab code into
hansl without being obliged to translate from matrices to a dataset.
So I don't see the "duplication" that you mention as a response to
list limitations. (Nor do I feel constrained by list limitations when
working with a dataset.)
Allin