11:24 a.m.
Dear all (and merry Xmas to you),
we don't have 3-D arrays like Matlab has, but we do have matrix arrays,
which you can more or less use to the same effect. I thought it would be
nice to have a function (provisionally called coresample(), as in those
holes you drill through the ground) that fills a matrix with selected
elements from a matrix array. Example script attached.
My questions are:
(i) is this useful enough to be made a standard function, or should we
just mention this kind of technique in the cheat sheet chapter (if at
all?)
(ii) in case the answer is yes, should we add this to libgretl or just
provide the function in the "extra" addon?
-------------------------------------------------------
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
-------------------------------------------------------
2:37 p.m.
On Tue, 25 Dec 2018, Riccardo (Jack) Lucchetti wrote:
Dear all (and merry Xmas to you),
we don't have 3-D arrays like Matlab has, but we do have matrix arrays, which
you can more or less use to the same effect. I thought it would be nice to
have a function (provisionally called coresample(), as in those holes you
drill through the ground) that fills a matrix with selected elements from a
matrix array. Example script attached.
My questions are:
(i) is this useful enough to be made a standard function, or should we just
mention this kind of technique in the cheat sheet chapter (if at all?)
It's certainly cute. I'm not sure about its usefulness -- do you
have applications in mind?
Allin
2:51 p.m.
On Tue, 25 Dec 2018, Allin Cottrell wrote:
On Tue, 25 Dec 2018, Riccardo (Jack) Lucchetti wrote:
> Dear all (and merry Xmas to you),
>
> we don't have 3-D arrays like Matlab has, but we do have matrix arrays,
> which you can more or less use to the same effect. I thought it would be
> nice to have a function (provisionally called coresample(), as in those
> holes you drill through the ground) that fills a matrix with selected
> elements from a matrix array. Example script attached.
>
> My questions are:
>
> (i) is this useful enough to be made a standard function, or should we just
> mention this kind of technique in the cheat sheet chapter (if at all?)
It's certainly cute. I'm not sure about its usefulness -- do you have
applications in mind?
One area could be the SVAR package: we currently store large matrices that
would be (perhaps) better organised as matrix arrays. For example, one
could store IRFS as an h-array of (n x n) matrices, or as an n-array of (h
x n) matrices (where h is the horizon and n is the number of variables in
the system). At that point, it'd just make sense to have functions to
extract the inforamtion you want in a clean and efficient way.
-------------------------------------------------------
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
-------------------------------------------------------
4:16 a.m.
Am 25.12.2018 um 20:51 schrieb Riccardo (Jack) Lucchetti:
On Tue, 25 Dec 2018, Allin Cottrell wrote:
> On Tue, 25 Dec 2018, Riccardo (Jack) Lucchetti wrote:
>
>> Dear all (and merry Xmas to you),
>>
>> we don't have 3-D arrays like Matlab has, but we do have matrix
>> arrays, which you can more or less use to the same effect. I thought
>> it would be nice to have a function (provisionally called
>> coresample(), as in those holes you drill through the ground) that
>> fills a matrix with selected elements from a matrix array.
I've had thoughts like this as well, I agree it's a natural wish.
>> (i) is this useful enough to be made a standard function, or
should
>> we just mention this kind of technique in the cheat sheet chapter (if
>> at all?)
Currently I don't think it should be a built-in function. Compared to
indexing and slicing in a 2-D matrix it is a workaround and looks second
class.
> It's certainly cute. I'm not sure about its usefulness --
do you have
> applications in mind?
one could store IRFS as an h-array of (n x n) matrices,
I think there are many applications, for example when you run
simulations and the 3rd dimension is a parameter that you're varying.
But OTOH you quickly get to the N-dim case, which is the reason why
languages like Python/Numpy have N-D arrays. So not so clear whether a
lot of effort should go into the 3-D case.
cheers,
sven
12:25 p.m.
On Wed, 26 Dec 2018, Sven Schreiber wrote:
Currently I don't think it should be a built-in function.
Compared to
indexing and slicing in a 2-D matrix it is a workaround and looks second
class.
[...]
I think there are many applications, for example when you run
simulations and
the 3rd dimension is a parameter that you're varying. But OTOH you quickly
get to the N-dim case, which is the reason why languages like Python/Numpy
have N-D arrays. So not so clear whether a lot of effort should go into the
3-D case.
On Thu, 27 Dec 2018, Ioannis A. Venetis wrote:
Very useful particularly in simulations as Sven mentioned but also
potentially in many big data applications
> (ii) in case the answer is yes, should we add this to libgretl or just
> provide the function in the "extra" addon?
The more functions (well documented and fast) the better... I would go
for libgretl
Ok, I've thought a little about it. I believe the best course of action
is the following:
(i) the function is there, anyone can use it in their own scripts (no
drawbacks that I can see)
(ii) if we find ourselves re-using this function over and over, then we
may add it to the extra package (drawback: it does look a bit clunky,
compared to n-dimensional arrays à la Juila/Python/Matlab, but OTOH I
don't see hansl having these in the foreseeable future, so we might as
well live with it).
(iii) if serious performance issues come up, implement it in C and make it
part of libgretl (drawback: I am a bit wary of having a
too-densely-populated namespace, but I'm open to changing my mind).
-------------------------------------------------------
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
-------------------------------------------------------
12:31 p.m.
Am 27.12.2018 um 18:25 schrieb Riccardo (Jack) Lucchetti:
Ok, I've thought a little about it. I believe the best course of
action
is the following:
(i) the function is there, anyone can use it in their own scripts (no
drawbacks that I can see)
If the use should be encouraged, then it would have to go either into
the guide/cheatsheet or into the 'extra' package. I believe a posting on
the mailing list has no widespread permanent effect. I only meant that
I'm skeptical about a core function (and the name could be debatable, too).
(BTW, isn't the mailing list going to switch over to your place, with a
relaunch in terms of additional web interface?)
cheers,
sven
3:48 a.m.
(i) is this useful enough to be made a standard function, or should we
just mention this kind of technique in the cheat sheet chapter (if at
all?)
Very useful particularly in simulations as Sven mentioned but also
potentially in many big data applications
(ii) in case the answer is yes, should we add this to libgretl or just
provide the function in the "extra" addon?
The more functions (well documented and fast) the better... I would go
for libgretl
(Merry Christmas and a Happy new year!)
Yiannis
2152
days inactive
2154
days old
6 comments
4 participants
participants (4)
-
Allin Cottrell -
Ioannis A. Venetis -
Riccardo (Jack) Lucchetti -
Sven Schreiber