4:36 p.m.
Hi,
I just found out that gretl's vec() and vech() functions have an
important difference: As duly documented, vec() stacks the columns (as
expected), but a little bit to my surprise vech() stacks the (relevant
parts of the) rows of the input. The latter property is not very
explicitly documented. (It just talks about the upper triangle of the
matrix, which at least is a hint in that direction.)
So basically to get the Wikipedia-style convention of the vech function
(https://en.wikipedia.org/wiki/Vectorization_(mathematics)#Half-vectorization)
we need to work on the transpose, vech(m').
This message just serves to share this "discovery". I'm not saying we
should change vech's behavior because that would break too much stuff.
But maybe a more explicit note should be added to the documentation.
(You may wonder why this matters at all, given that the input typically
should be symmetric; but I had to work with some code that just fills
the lower triangle of a matrix and then expands this to a symmetric
matrix. So the input there wasn't symmetric, by design.)
thanks
sven
8:18 p.m.
On Thu, 17 Dec 2020, Sven Schreiber wrote:
Hi,
I just found out that gretl's vec() and vech() functions have an
important difference: As duly documented, vec() stacks the columns (as
expected), but a little bit to my surprise vech() stacks the (relevant
parts of the) rows of the input. The latter property is not very
explicitly documented. (It just talks about the upper triangle of the
matrix, which at least is a hint in that direction.)
So basically to get the Wikipedia-style convention of the vech function
(https://en.wikipedia.org/wiki/Vectorization_(mathematics)#Half-vectorization)
we need to work on the transpose, vech(m').
This message just serves to share this "discovery". I'm not saying we
should change vech's behavior because that would break too much stuff.
But maybe a more explicit note should be added to the documentation.
What should the message say? Seems like it would have to be
something like: If your input matrix is not symmetric, make sure the
upper triangle is what it would be if the matrix were symmetric. But
that sounds kinda redundant to me.
Allin
8:23 p.m.
Am 17.12.2020 um 21:18 schrieb Allin Cottrell:
On Thu, 17 Dec 2020, Sven Schreiber wrote:
>
> This message just serves to share this "discovery". I'm not saying we
> should change vech's behavior because that would break too much stuff.
> But maybe a more explicit note should be added to the documentation.
What should the message say? Seems like it would have to be something
like: If your input matrix is not symmetric, make sure the upper
triangle is what it would be if the matrix were symmetric. But that
sounds kinda redundant to me.
Well, maybe something like: "For the odd case of non-symmetric input M,
to obtain the same result as the vech functions in Gauss or Octave or as
per the Wikipedia definition, use the transpose of M to effectively work
on its lower triangle."
thanks
sven
8:38 p.m.
On Thu, 17 Dec 2020, Sven Schreiber wrote:
Am 17.12.2020 um 21:18 schrieb Allin Cottrell:
> On Thu, 17 Dec 2020, Sven Schreiber wrote:
>
>>
>> This message just serves to share this "discovery". I'm not saying
we
>> should change vech's behavior because that would break too much stuff.
>> But maybe a more explicit note should be added to the documentation.
>
> What should the message say? Seems like it would have to be something
> like: If your input matrix is not symmetric, make sure the upper
> triangle is what it would be if the matrix were symmetric. But that
> sounds kinda redundant to me.
>
>
Well, maybe something like: "For the odd case of non-symmetric input M,
to obtain the same result as the vech functions in Gauss or Octave or as
per the Wikipedia definition, use the transpose of M to effectively work
on its lower triangle."
OK, better than my attempt. But non-symmetry in itself is not the
decider. If the upper triangle is "right" and the rest is zeros (or
arbitrary), vech(M) is right and vech(M') wrong. The case where you
need vech(M') is just where the upper triangle is arbitrary, and
what you actually want is in the lower triangle.
Allin
8:51 p.m.
Am 17.12.2020 um 21:38 schrieb Allin Cottrell:
On Thu, 17 Dec 2020, Sven Schreiber wrote:
> Am 17.12.2020 um 21:18 schrieb Allin Cottrell:
>> On Thu, 17 Dec 2020, Sven Schreiber wrote:
>>
>> What should the message say? Seems like it would have to be something
>> like: If your input matrix is not symmetric, make sure the upper
>> triangle is what it would be if the matrix were symmetric. But that
>> sounds kinda redundant to me.
>>
>>
> Well, maybe something like: "For the odd case of non-symmetric input M,
> to obtain the same result as the vech functions in Gauss or Octave or as
> per the Wikipedia definition, use the transpose of M to effectively work
> on its lower triangle."
OK, better than my attempt. But non-symmetry in itself is not the
decider. If the upper triangle is "right" and the rest is zeros (or
arbitrary), vech(M) is right and vech(M') wrong. The case where you
need vech(M') is just where the upper triangle is arbitrary, and what
you actually want is in the lower triangle.
Yes, I agree. The thing is just that gretl here seems to be the outlier,
"everybody" else --OK, haven't looked very hard-- seems to use the lower
triangle. And once you start departing from the convention, then from
the doc it isn't 100% clear that gretl's vech doesn't half-stack the
upper triangle by columns instead of rows. (Fortunately it doesn't, of
course.)
To be clear about the background:
The Gauss code I was looking at populated element by element the lower
triangle of a matrix M that would become a covariance matrix. Then it
did xpnd(vech(M)) to get the dense symmetric matrix. (Where xpnd is what
unvech is in gretl.) There the convention about the triangles obviously
matter, and again, I simply didn't expect gretl's variant.
thanks
sven
1471
days inactive
1471
days old
4 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber