1:17 a.m.
On Tue, 1 Nov 2011, artur bala wrote:
Another point (which was my original one): the [column or row]
names are not saved when a matrix is returned from a function.
True. Here's a minimal case:
<hansl>
function matrix mnames (void)
matrix m = I(3)
colnames(m, "col1 col2 col3")
print m
return m
end function
matrix m = mnames()
print m
</hansl>
Initially I thought this might be a simple bug that could easily be
fixed, but actually it turns out it's a design issue (and hence I'm
copying gretl-devel, hoping for comments).
The point is that the gretl_matrix type knows nothing about column
or row names. These names reside at the level of the "user_matrix"
struct which wraps a locally named gretl_matrix for ease of use. But
when a function returns a matrix, it returns a plain gretl_matrix:
the names are destroyed and not returned.
The main reason that the names are attached to the "user_matrix"
wrapper and not the gretl_matrix itself is to keep the gretl_matrix
type lean and mean. After all, it's used internally in many contexts
where column/row names are never wanted, and it's also offered as a
type for matrix operations by third parties (the libgretl API)
where, again, name-pointers are likely to be just a deadweight.
On the other hand, I can see a use-case for wanting to return a
matrix from a user-defined function with row and/or column names
attached. Right now, I'm not sure how to resolve this.
Allin
3:09 a.m.
New subject: [Gretl-users] saving the row/col names of a matrix
On Tue, 1 Nov 2011, Allin Cottrell wrote:
The point is that the gretl_matrix type knows nothing about column
or row names. [...]
The main reason that the names are attached to the "user_matrix"
wrapper and not the gretl_matrix itself is to keep the
gretl_matrix type lean and mean. [...]
On the other hand, I can see a use-case for wanting to return a
matrix from a user-defined function with row and/or column names
attached. Right now, I'm not sure how to resolve this.
A brief follow-up. I may be missing a better alternative (and I'll
continue to think about what that might be), but as I see it right
now, enabling user-functions to return matrices with row or column
names attached would require either:
(a) Functions can return the user_matrix wrapper-type, not just
plain gretl_matrix. I think this is a non-starter. Gretl's geneval.c
is complex enough, and hard enough to maintain, at present. This
would be bug-heaven; or
(b) Row and/or column names are attached to the gretl_matrix struct
itself, rather than the wrapper. That is more plausible, but I still
don't like it much. The extra memory required for an empty
gretl_matrix would only be two pointers (8 bytes on a 32-bit system)
but it represents additional complexity that I'd prefer to keep out
of what is in concept a mathematical type.
Allin
7:03 a.m.
New subject: [Gretl-users] saving the row/col names of a matrix
On Tue, 1 Nov 2011, Allin Cottrell wrote:
(b) Row and/or column names are attached to the gretl_matrix struct
itself, rather than the wrapper. That is more plausible, but I still
don't like it much. The extra memory required for an empty
gretl_matrix would only be two pointers (8 bytes on a 32-bit system)
but it represents additional complexity that I'd prefer to keep out
of what is in concept a mathematical type.
I agree: matrices should stay as lean-and-mean as possible. Besides, there
is the possibility of achieving Artur's original aim in Hansl, albeit in a
way that most people will find a bit convoluted: here's two ways to do it.
My personal preference goes to func2, but I happen to like bundles quite a
lot.
<hansl>
set echo off
set messages off
function string func1(scalar r, scalar c, matrix *m)
string rl = ""
loop i=1..r --quiet
sprintf rl "%s,row_%d", rl, i
end loop
string cl = ""
loop i=1..c --quiet
sprintf cl "%s,col_%d", cl, i
end loop
m = zeros(r,c)
sprintf ret "%s %s", rl, cl
return ret
end function
function bundle func2(scalar r, scalar c)
bundle ret
string rl = ""
loop i=1..r --quiet
sprintf rl "%s,row_%d", rl, i
end loop
ret["Rlab"] = rl
string cl = ""
loop i=1..c --quiet
sprintf cl "%s,col_%d", cl, i
end loop
ret["Clab"] = cl
m = zeros(r,c)
ret["X"] = m
return ret
end function
# ----- using func1 -----------------------------
a = {}
boo = func1(3,2,&a)
rowlab = strsub(strsplit(boo, 1), ",", " ")
collab = strsub(strsplit(boo, 2), ",", " ")
rownames(a, rowlab)
colnames(a, collab)
print a
# ----- using func2 -----------------------------
bundle zoo = func2(3,2)
rowlab = zoo["Rlab"]
collab = zoo["Clab"]
a = zoo["X"]
rownames(a, rowlab)
colnames(a, collab)
print a
</hansl>
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
7:17 a.m.
New subject: [Gretl-users] saving the row/col names of a matrix
On Wed, 2 Nov 2011, Riccardo (Jack) Lucchetti wrote:
On Tue, 1 Nov 2011, Allin Cottrell wrote:
> (b) Row and/or column names are attached to the gretl_matrix struct
> itself, rather than the wrapper. That is more plausible, but I still
> don't like it much. The extra memory required for an empty
> gretl_matrix would only be two pointers (8 bytes on a 32-bit system)
> but it represents additional complexity that I'd prefer to keep out
> of what is in concept a mathematical type.
I agree: matrices should stay as lean-and-mean as possible. Besides, there is
the possibility of achieving Artur's original aim in Hansl, albeit in a way
that most people will find a bit convoluted: here's two ways to do it. My
personal preference goes to func2, but I happen to like bundles quite a lot.
Sorry for the noise: (1) I forgot to send my previous message to the
users' list; (2) there was a small glitch in func2 (corrected below); (3)
I'd like to express my point more explicitly: IMO, base types such as
matrices should stay as unencumbered by extra info (or metadata, call it
what you want) in the interest of efficiency. If you really need to wrap
up a complex set of information into one entity, that's exactly what
bundles are for.
<hansl>
set echo off
set messages off
function string func1(scalar r, scalar c, matrix *m)
string rl = ""
loop i=1..r --quiet
sprintf rl "%s,row_%d", rl, i
end loop
string cl = ""
loop i=1..c --quiet
sprintf cl "%s,col_%d", cl, i
end loop
m = zeros(r,c)
sprintf ret "%s %s", rl, cl
return ret
end function
function bundle func2(scalar r, scalar c)
bundle ret
string rl = ""
loop i=1..r --quiet
sprintf rl "%s row_%d", rl, i
end loop
ret["Rlab"] = rl
string cl = ""
loop i=1..c --quiet
sprintf cl "%s col_%d", cl, i
end loop
ret["Clab"] = cl
m = zeros(r,c)
ret["X"] = m
return ret
end function
# ----- using func1 -----------------------------
a = {}
boo = func1(3,2,&a)
rowlab = strsub(strsplit(boo, 1), ",", " ")
collab = strsub(strsplit(boo, 2), ",", " ")
rownames(a, rowlab)
colnames(a, collab)
print a
# ----- using func2 -----------------------------
bundle zoo = func2(3,2)
rowlab = zoo["Rlab"]
collab = zoo["Clab"]
a = zoo["X"]
rownames(a, rowlab)
colnames(a, collab)
print a
</hansl>
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
8:41 p.m.
New subject: [Gretl-users] saving the row/col names of a matrix
On Wed, 2 Nov 2011, Riccardo (Jack) Lucchetti wrote:
On Tue, 1 Nov 2011, Allin Cottrell wrote:
> (b) Row and/or column names are attached to the gretl_matrix struct
> itself, rather than the wrapper. That is more plausible, but I still
> don't like it much. The extra memory required for an empty
> gretl_matrix would only be two pointers (8 bytes on a 32-bit system)
> but it represents additional complexity that I'd prefer to keep out
> of what is in concept a mathematical type.
I agree: matrices should stay as lean-and-mean as possible.
Besides, there is the possibility of achieving Artur's
original aim in Hansl, albeit in a way that most people will
find a bit convoluted: here's two ways to do it [...]
Thanks, Jack. These functions nicely illustrate what you can
do with bundles.
But after some more thinking I think I may have come up with a
solution to the matrix column/row names issue which satisfies
the "lean and mean" criterion as well as allowing a simple way
to return decorated matrices from functions.
The thing is, we already have some "metadata" in the
gretl_matrix struct, namely the two integer members "t1" and
"t2". These are bloat from the point of view of pure matrix
arithmetic, but gretl needs them in many contexts for keeping
track of the alignment between matrices and series. My new
idea is this:
Remove t1 and t2 as members of gretl_matrix and replace them
with a single pointer member (so gretl_matrix becomes leaner
by 4 bytes). This pointer member is just NULL by default, but
one it's allocated it has space to record t1 and t2, as well
as column and/or row names if wanted.
The metadata struct that can be allocated on a gretl_matrix is
a private thing that lives in gretl_matrix.c. Anything you
want to do with it (get/set t1, t2 or names) you do via
accessor functions -- and the "set" accessors take care of
allocating the storage as needed.
I'm not committing this change just yet since it needs more
testing, but I'm hopeful it'll do the job.
Allin
8:58 p.m.
New subject: [Gretl-users] saving the row/col names of a matrix
On Wed, 2 Nov 2011, Allin Cottrell wrote:
On Wed, 2 Nov 2011, Riccardo (Jack) Lucchetti wrote:
> On Tue, 1 Nov 2011, Allin Cottrell wrote:
>
>> (b) Row and/or column names are attached to the gretl_matrix struct
>> itself, rather than the wrapper. That is more plausible, but I still
>> don't like it much. The extra memory required for an empty
>> gretl_matrix would only be two pointers (8 bytes on a 32-bit system)
>> but it represents additional complexity that I'd prefer to keep out
>> of what is in concept a mathematical type.
>
> I agree: matrices should stay as lean-and-mean as possible. Besides, there
> is the possibility of achieving Artur's original aim in Hansl, albeit in a
> way that most people will find a bit convoluted: here's two ways to do it
> [...]
Thanks, Jack. These functions nicely illustrate what you can do with bundles.
But after some more thinking I think I may have come up with a solution to
the matrix column/row names issue which satisfies the "lean and mean"
criterion as well as allowing a simple way to return decorated matrices from
functions. [...]
I'm not committing this change just yet since it needs more testing, but I'm
hopeful it'll do the job.
I've now done enough checking to say that nothing obvious is
broken with the changes I mentioned, so I'm now putting them
into CVS. But I'll do some more testing over the next few
days.
Allin
5:46 a.m.
New subject: [Gretl-users] saving the row/col names of a matrix
On Wed, 2 Nov 2011, Allin Cottrell wrote:
Remove t1 and t2 as members of gretl_matrix and replace them with a
single
pointer member (so gretl_matrix becomes leaner by 4 bytes). This pointer
member is just NULL by default, but one it's allocated it has space to record
t1 and t2, as well as column and/or row names if wanted.
This sounds like a brilliant idea to me. In a typical usage scenario, the
pointer will stay NULL in most cases, but has the potential to act like a
hook for appending any sort of metadata, if needed. Did I get this right?
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
1:17 p.m.
New subject: [Gretl-users] saving the row/col names of a matrix
On Thu, 3 Nov 2011, Riccardo (Jack) Lucchetti wrote:
On Wed, 2 Nov 2011, Allin Cottrell wrote:
> Remove t1 and t2 as members of gretl_matrix and replace them with a single
> pointer member (so gretl_matrix becomes leaner by 4 bytes). This pointer
> member is just NULL by default, but one it's allocated it has space to
> record t1 and t2, as well as column and/or row names if wanted.
This sounds like a brilliant idea to me. In a typical usage scenario, the
pointer will stay NULL in most cases, but has the potential to act like a
hook for appending any sort of metadata, if needed. Did I get this right?
Just about -- except that as things stand the hook (which
usually stays NULL, yes) is specified as a pointer to a
(private) structure called matrix_info_, which includes slots
for two integers (t1 and t2) and two char ** pointers intended
for arrays of names. That is, it's not just a general void *
pointer that could be used to attach any metadata.
Allowing the more general case would obviously give more
flexibility, but it would also increase complexity. For
example, when libgretl wants to read t1 and t2 from a matrix
what happens? Right now all we have to do is check that the
"matrix_info" pointer on the matrix is non-NULL and we know it
must hold t1 and t2 values. If the metadata pointer could hold
anything, we'd need some way of finding out what the heck it
holds.
Allin
4797
days inactive
4798
days old
7 comments
2 participants
participants (2)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti