7:52 a.m.
Good morning,
I just noticed the new (?) function diagcat() with the following help text:
"Returns the direct sum of A and B, that is a block-diagonal matrix
holding A in its north-west corner and B in its south-east corner. "
Why would that be a _sum_?
Also, what happens if A and B are not square? (I know, I could just try
that out, but too lazy, and that wouldn't necessarily answer what's
intended as a result.)
And while I'm at it: I also noticed trimr() which trims rows. Don't know
whether that's new, but why introduce a special function for this
operation, couldn't it always be easily done by indexing, as in
M[ttop+1:rows(M)-tbot] ?
cheers,
sven
8:33 a.m.
On Fri, 28 Sep 2012, Sven Schreiber wrote:
Good morning,
I just noticed the new (?) function diagcat() with the following help text:
"Returns the direct sum of A and B, that is a block-diagonal matrix
holding A in its north-west corner and B in its south-east corner. "
Why would that be a _sum_?
Because that's its name :)
http://en.wikipedia.org/wiki/Matrix_addition#Direct_sum
Intuitively, you can think of this operator as a sum if you view matrices
as the space spanned by their columns. The direct sum of two matrices
results in a space which is equal to the two original spaces "put
together", so to speak.
Also, what happens if A and B are not square? (I know, I could just
try
that out, but too lazy, and that wouldn't necessarily answer what's
intended as a result.)
Nothing spectacular. You just have non-square zero blocks in the
north-east and south-west corners of the result.
And while I'm at it: I also noticed trimr() which trims rows.
Don't know
whether that's new, but why introduce a special function for this
operation, couldn't it always be easily done by indexing, as in
M[ttop+1:rows(M)-tbot] ?
It's been around for a while. Maybe you're right. We may want to suppress
a few redundant functions for 2.0.
--------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
--------------------------------------------------
8:41 a.m.
On 09/28/2012 10:33 AM, Riccardo (Jack) Lucchetti wrote:
On Fri, 28 Sep 2012, Sven Schreiber wrote:
> Good morning,
>
> I just noticed the new (?) function diagcat() with the following help
> text:
>
> "Returns the direct sum of A and B, that is a block-diagonal matrix
> holding A in its north-west corner and B in its south-east corner. "
>
> Why would that be a _sum_?
Because that's its name :)
http://en.wikipedia.org/wiki/Matrix_addition#Direct_sum
Intuitively, you can think of this operator as a sum if you view
matrices as the space spanned by their columns. The direct sum of two
matrices results in a space which is equal to the two original spaces
"put together", so to speak.
Well, one never stops learning I guess. I trust you didn't write that
Wikipedia entry yourself ;-)
> Also, what happens if A and B are not square? (I know, I could just try
> that out, but too lazy, and that wouldn't necessarily answer what's
> intended as a result.)
Nothing spectacular. You just have non-square zero blocks in the
north-east and south-west corners of the result.
At the risk of being pedantic: so a block-diagonal matrix is only
returned if the inputs are square, otherwise it's just a block matrix.
(w.r.t. the help text)
thanks,
sven
10:20 a.m.
On Fri, 28 Sep 2012, Sven Schreiber wrote:
>> Also, what happens if A and B are not square? (I know, I
could just try
>> that out, but too lazy, and that wouldn't necessarily answer what's
>> intended as a result.)
>
> Nothing spectacular. You just have non-square zero blocks in the
> north-east and south-west corners of the result.
>
At the risk of being pedantic: so a block-diagonal matrix is only
returned if the inputs are square, otherwise it's just a block matrix.
(w.r.t. the help text)
You're right, fixed in CVS. Also, my previous comment was wrong: when A
and B are not square, the zero NE and SW blocks of the resulting matrix
are not the transpose of each other. At the risk of being pedantic!
--------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
--------------------------------------------------
9:31 p.m.
On Fri, 28 Sep 2012, Sven Schreiber wrote:
And while I'm at it: I also noticed trimr() which trims rows.
Don't know
whether that's new, but why introduce a special function for this
operation, couldn't it always be easily done by indexing, as in
M[ttop+1:rows(M)-tbot] ?
It could. But one point to bear in mind (apart from
user-friendliness) is that a built-in shortcut such a trimr()
is in principle more efficient than the long-hand version, since it
involves less parsing of user input. Whether that's of practical
importance, I'm not sure.
Allin Cottrell
10:41 p.m.
fwiw ($0.02?), I find the trimr function very useful. It helps when translating, for
example.
PS
________________________________________
From: gretl-users-bounces(a)lists.wfu.edu [gretl-users-bounces(a)lists.wfu.edu] on behalf of
Allin Cottrell [cottrell(a)wfu.edu]
Sent: Friday, September 28, 2012 5:31 PM
To: Gretl list
Subject: Re: [Gretl-users] diagcat
On Fri, 28 Sep 2012, Sven Schreiber wrote:
And while I'm at it: I also noticed trimr() which trims rows.
Don't know
whether that's new, but why introduce a special function for this
operation, couldn't it always be easily done by indexing, as in
M[ttop+1:rows(M)-tbot] ?
It could. But one point to bear in mind (apart from
user-friendliness) is that a built-in shortcut such a trimr()
is in principle more efficient than the long-hand version, since it
involves less parsing of user input. Whether that's of practical
importance, I'm not sure.
Allin Cottrell
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
11:03 p.m.
On Fri, 28 Sep 2012, Summers, Peter wrote:
fwiw ($0.02?), I find the trimr function very useful. It helps
when translating, for example.
Thanks, Peter. That comment jogs my memory: I think I introduced it
for ease of translation from another matrix-processing language.
Allin.
On Fri, 28 Sep 2012, Sven Schreiber wrote:
> And while I'm at it: I also noticed trimr() which trims rows. Don't know
> whether that's new, but why introduce a special function for this
> operation, couldn't it always be easily done by indexing, as in
> M[ttop+1:rows(M)-tbot] ?
It could. But one point to bear in mind (apart from
user-friendliness) is that a built-in shortcut such a trimr()
is in principle more efficient than the long-hand version, since it
involves less parsing of user input. Whether that's of practical
importance, I'm not sure.
Allin Cottrell
4480
days inactive
4480
days old
6 comments
4 participants
participants (4)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti -
Summers, Peter -
Sven Schreiber