2:29 p.m.
Hi,
I'm noticing that the plain cholesky-based C matrix which is stored
after 'var' estimation in $system.C is not square. For example
estimating a 2-dim VAR with 2 lags I get a 4x2 matrix there; however the
bottom half is just zero, and the top is equal to cholesky($sigma) alright.
It seems to come from VAR_allocate_cholesky_matrix in lib/src/var.c,
where we have:
n = var->neqns * effective_order(var);
var->C = gretl_zero_matrix_new(n, var->neqns);
So the number of rows is indeed chosen as dim x lagorder which explains
my row number 4 above - but this doesn't make any sense, does it?
(Internally it doesn't seem to do any harm since the bottom is then not
used apparently. But it surfaces in the $system bundle as a weird thing.)
Maybe after release we could experiment with just dropping the lower
half and see if it still works...
thanks
sven
9:26 a.m.
On Fri, 20 Nov 2020, Sven Schreiber wrote:
Hi,
I'm noticing that the plain cholesky-based C matrix which is stored
after 'var' estimation in $system.C is not square. For example
estimating a 2-dim VAR with 2 lags I get a 4x2 matrix there; however the
bottom half is just zero, and the top is equal to cholesky($sigma) alright.
It seems to come from VAR_allocate_cholesky_matrix in lib/src/var.c,
where we have:
n = var->neqns * effective_order(var);
var->C = gretl_zero_matrix_new(n, var->neqns);
So the number of rows is indeed chosen as dim x lagorder which explains
my row number 4 above - but this doesn't make any sense, does it?
That C matrix is described in var.h as "augmented
Cholesky-decomposed error matrix". I can't say I remember the exact
reason for augmenting it with zeros, but as things stand it's
required for conformability in functions such as
gretl_VAR_get_fcast_decomp(). Just making C square would definitely
break things, though there may be a smarter approach that doesn't
need the augmentation. (At a quick peek, this might require
replacement of a straight matrix addition with addition of a small
matrix to a region of a larger one.)
Even if we decide using the augmented C is more efficient for
internal usage, we could trim it when writing to the $system bundle.
Allin
10:03 a.m.
Am 21.11.2020 um 15:26 schrieb Allin Cottrell:
On Fri, 20 Nov 2020, Sven Schreiber wrote:
>
> It seems to come from VAR_allocate_cholesky_matrix in lib/src/var.c,
> where we have:
>
> n = var->neqns * effective_order(var);
> var->C = gretl_zero_matrix_new(n, var->neqns);
>
> So the number of rows is indeed chosen as dim x lagorder which explains
> my row number 4 above - but this doesn't make any sense, does it?
That C matrix is described in var.h as "augmented Cholesky-decomposed
error matrix". I can't say I remember the exact reason for augmenting it
with zeros, but as things stand it's required for conformability in
functions such as gretl_VAR_get_fcast_decomp(). Just making C square
would definitely break things, though there may be a smarter approach
that doesn't need the augmentation. (At a quick peek, this might require
replacement of a straight matrix addition with addition of a small
matrix to a region of a larger one.)
Even if we decide using the augmented C is more efficient for internal
usage, we could trim it when writing to the $system bundle.
Right, I think that would be the natural way. Another thing for after
release.
thanks
sven
10:47 a.m.
On Sat, 21 Nov 2020, Sven Schreiber wrote:
Am 21.11.2020 um 15:26 schrieb Allin Cottrell:
> On Fri, 20 Nov 2020, Sven Schreiber wrote:
>>
>> It seems to come from VAR_allocate_cholesky_matrix in lib/src/var.c,
>> where we have:
>>
>> n = var->neqns * effective_order(var);
>> var->C = gretl_zero_matrix_new(n, var->neqns);
>>
>> So the number of rows is indeed chosen as dim x lagorder which explains
>> my row number 4 above - but this doesn't make any sense, does it?
>
> That C matrix is described in var.h as "augmented Cholesky-decomposed
> error matrix". I can't say I remember the exact reason for augmenting it
> with zeros, but as things stand it's required for conformability in
> functions such as gretl_VAR_get_fcast_decomp().
I think I understand it now. That C matrix augmented with a bunch of
rows of zeros is a device one would use in giving a compact account
of the algorithm for IRFs and FEVDs. One can construct it literally
in code but that's not efficient -- better to keep C square and just
calculate "as if" it had zeros in train. That's what we now do in
git.
(Algorithmic accounts of estimators quite often feature big matrices
that offer notational economy, but that it would be silly to
actually construct. Mostly libgretl avoids that kind of silliness.)
Allin
11:03 a.m.
Am 22.11.2020 um 16:47 schrieb Allin Cottrell:
On Sat, 21 Nov 2020, Sven Schreiber wrote:
> Am 21.11.2020 um 15:26 schrieb Allin Cottrell:
>> On Fri, 20 Nov 2020, Sven Schreiber wrote:
>
>>>
>>> It seems to come from VAR_allocate_cholesky_matrix in lib/src/var.c,
>>> where we have:
>>>
>>> n = var->neqns * effective_order(var);
>>> var->C = gretl_zero_matrix_new(n, var->neqns);
>>>
>>> So the number of rows is indeed chosen as dim x lagorder which explains
>>> my row number 4 above - but this doesn't make any sense, does it?
>>
>> That C matrix is described in var.h as "augmented Cholesky-decomposed
>> error matrix". I can't say I remember the exact reason for augmenting
it
>> with zeros, but as things stand it's required for conformability in
>> functions such as gretl_VAR_get_fcast_decomp().
I think I understand it now. That C matrix augmented with a bunch of
rows of zeros is a device one would use in giving a compact account of
the algorithm for IRFs and FEVDs. One can construct it literally in code
but that's not efficient -- better to keep C square and just calculate
"as if" it had zeros in train. That's what we now do in git.
OK, so I guess this automatically makes $system.C on the hansl side then
also square in the future?
thanks
sven
11:16 a.m.
On Sun, 22 Nov 2020, Sven Schreiber wrote:
Am 22.11.2020 um 16:47 schrieb Allin Cottrell:
> On Sat, 21 Nov 2020, Sven Schreiber wrote:
>
>> Am 21.11.2020 um 15:26 schrieb Allin Cottrell:
>>> On Fri, 20 Nov 2020, Sven Schreiber wrote:
>>
>>>>
>>>> It seems to come from VAR_allocate_cholesky_matrix in lib/src/var.c,
>>>> where we have:
>>>>
>>>> n = var->neqns * effective_order(var);
>>>> var->C = gretl_zero_matrix_new(n, var->neqns);
>>>>
>>>> So the number of rows is indeed chosen as dim x lagorder which explains
>>>> my row number 4 above - but this doesn't make any sense, does it?
>>>
>>> That C matrix is described in var.h as "augmented Cholesky-decomposed
>>> error matrix". I can't say I remember the exact reason for
augmenting it
>>> with zeros, but as things stand it's required for conformability in
>>> functions such as gretl_VAR_get_fcast_decomp().
>
> I think I understand it now. That C matrix augmented with a bunch of
> rows of zeros is a device one would use in giving a compact account of
> the algorithm for IRFs and FEVDs. One can construct it literally in code
> but that's not efficient -- better to keep C square and just calculate
> "as if" it had zeros in train. That's what we now do in git.
OK, so I guess this automatically makes $system.C on the hansl side then
also square in the future?
Yes.
Allin
3:15 p.m.
New subject: compan/A/sysA etc. (was Re: Re: why non-square $system.C after var?)
Am 22.11.2020 um 17:16 schrieb Allin Cottrell:
On Sun, 22 Nov 2020, Sven Schreiber wrote:
> OK, so I guess this automatically makes $system.C on the hansl
side then
> also square in the future?
Yes.
Alright, let me continue this thread with some other quirks in the
$system bundle area. I will try to be explicit when that bundle comes
from a 'var' command or from a 'system' block, because that's
sometimes
part of the confusion.
- endog_vars, list bundle member after 'system': IMHO this should be
called "ylist" just like the direct $-accessor and $system.ylist after
'var' are called. (I first thought that maybe endog_vars could hold more
than N variables --and thus more than $ylist-- because of non-modelled
variables that are still treated as needing to be instrumented, but I
tested that possibility and instead I get an error. So that's not a
reason to differentiate $system.endog_vars and $ylist.)
- list1...list<N> after 'system': These should be collected in a lists
array, perhaps called $system.eqnvars. (But this is just a feature
request, not a resolution of any problem.)
- xlist after 'system': the direct accessor $xlist exists but
$system.xlist doesn't -> should be added.
- xlist, 'var' vs. 'system': in the 'system' case this contains
deterministic terms, while with 'var' it doesn't. Maybe it would be good
to adjust the 'var' case. (This would be backwards-incompatible but I
see no easy solution.)
- A / compan / sysA: This is a bit of a mess...
* First of all after 'var' we have $compan, so we should probably add
$system.compan as an alias for $system.A.
* Then after 'system' we have $sysA which is the same as $system.A, but
maybe the link would be even more explicit if it were also $system.sysA.
(By implication then also add $system.sysB in addition to $system.B, and
the same for $system.sysGamma.)
* But note that for equivalent specifications the result $system.A after
'system' is just the top of the (companion matrix) result $system.A
after 'var'. I think the best solution would be to deprecate $system.A
in both cases (but keep them around as-is for now), once the different
aliases $system.compan (for 'var') and $system.sysA (for 'system') are
added.
* sysGamma: Not very important, but it would be easy in the 'var' case
to add an identity matrix to the bundle taking that role.
OK sorry, that's a long list, but I spent quite some time getting to
grips with the details of the current status quo there.
thanks
sven
1453
days inactive
1455
days old
6 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber