12:35 p.m.
Hello,
this time no bug report but a feature request.
I think there is a pretty obvious feature that's missing and that's
enabling conversion from matrices to lists, to facilitate roundtripping
list - matrix - list. What I have in mind is something like this workaround:
<hansl>
function list mat2list(matrix inmat)
list lout = null # initialize
loop i=1..cols(inmat)
series stemp = inmat[,i]
list lout += stemp
endloop
return lout
end function
</hansl>
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?
The thing is that currently lists and matrices in gretl are
complementary; you cannot use matrices in estimation commands for
example, and you cannot apply many calculations to lists. So I think we
need to ensure quick and easy conversion from one type to the other.
In terms of syntax, I wouldn't mind an explicit function like mat2list()
above, to be built-in. What do you think?
thanks,
sven
1:09 p.m.
On Sun, 11 Jan 2015, Sven Schreiber wrote:
Hello,
this time no bug report but a feature request.
I think there is a pretty obvious feature that's missing and that's
enabling conversion from matrices to lists, to facilitate roundtripping
list - matrix - list. What I have in mind is something like this workaround:
<hansl>
function list mat2list(matrix inmat)
list lout = null # initialize
loop i=1..cols(inmat)
series stemp = inmat[,i]
list lout += stemp
endloop
return lout
end function
</hansl>
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.
The thing is that currently lists and matrices in gretl are
complementary; you cannot use matrices in estimation commands for
example, and you cannot apply many calculations to lists.
The good thing about matrices is that you're free from the tyranny of
$nobs. Also, don't forget that we have lincomb(), which I find very
useful, plus a host of other functions for lists, such as nelem(), sum(),
sd(), max(), min() etc.
So I think we need to ensure quick and easy conversion from one type
to
the other. In terms of syntax, I wouldn't mind an explicit function
like mat2list() above, to be built-in. What do you think?
I don't know, I can't see myself using this a lot, but maybe it's just me.
-------------------------------------------------------
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
-------------------------------------------------------
1:24 p.m.
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.
> The thing is that currently lists and matrices in gretl are
> complementary; you cannot use matrices in estimation commands for
> example, and you cannot apply many calculations to lists.
The good thing about matrices is that you're free from the tyranny of
$nobs. Also, don't forget that we have lincomb(), which I find very
useful, plus a host of other functions for lists, such as nelem(),
sum(), sd(), max(), min() etc.
I haven't forgotten those, but they are far from complete, for the same
naming issues that you pointed out. But you're right (again) in that an
alternative route could be to enable more arithmetic functions with
lists. However, the a priori arbitrary naming of the resulting series
would then involve more hardwired choices like the "d_" and "l_"
prefixes for diffs and lags.
> So I think we need to ensure quick and easy conversion from one type
> to the other. In terms of syntax, I wouldn't mind an explicit
> function like mat2list() above, to be built-in. What do you think?
I don't know, I can't see myself using this a lot, but maybe it's just me.
My impression from your 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.
cheers,
sven
6:27 p.m.
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
9:03 p.m.
Am 11.01.2015 um 19:27 schrieb Allin Cottrell:
On Sun, 11 Jan 2015, Sven Schreiber wrote:
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():
I don't have anything against adding functionality via function
(packages). Perhaps a kind of "utilities" package could actually be
useful that contains a collection of smallish functions like this one.
Then you would just need to remember to do "include utilitites.gfn" at
the top.
Also, yes as I said I agree it should be possible for the user to
specify the names. Just provide an array of strings or somesuch as a
second argument: "list outlist = mat2list(inlist, snames)". Then we
could discuss whether that could become optional with some default. But
I don't see a deep issue here.
OK, let's do so ;-) IMO, while working with a dataset, series and
lists is often very convenient,
...
(Nor do I feel constrained by list limitations when
working with a dataset.)
Partly this depends on what you want to do. For example, specifying an
equation system is only possible via special list constructions (AFAIK).
And if the variables that you want to specify there are not straight in
your dataset already, chances are that you cook them together via matrix
operations, because of the list limitations. I think there are other
examples as well.
But there is a broader point IMHO: If you have a non-trivial task, you
often want to or should split your code into modular functions. And
because then some of your functions expect a list argument as input,
some other preparatory functions would need to return lists as output.
And this is currently not as easy as it could be.
I guess my bottom line is, if lists are supposed to be first-class
objects, stuff like this little conversion function would be good IMHO.
But if the motto somehow is that one should just accept the list
limitations, then I would like to be able to actually avoid lists more
than is currently possible. This would involve changes or additions in
other areas, see my example regarding equation systems.
thanks,
sven
3633
days inactive
3633
days old
4 comments
3 participants
participants (3)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti -
Sven Schreiber