5:20 p.m.
Dear Prof,
I am aware that the code 'SVAR_restrict(&x, "C", 1, 2, 0)' is to
inform
Gretl of the nature of the restriction to estimate. I also know that this
has to be repeated for several restrictions like in the model. However, I
consider this to be rigorous especially when a large matrix is involved.
Although, I know how a matrix can be created and used with the SVAR GUI, I
don't know how it can be used with the SVAR_restrict(&x, ) function.
Please, I need to be enlighten if this is possible or if I have to do the
imputation for each restriction.
Thanks.
1 p.m.
Am 28.12.2023 um 21:02 schrieb Olasehinde Timmy:
OK sir. Thanks for the response. Nevertheless, I would suggest that
the SVAR/SVEC GUI is updated to include the space for names of shocks
just like the space provided for indexing the irf to cumulate.
Regards
John
Hello Timmy (or John?) after quite some time,
this email thread is almost one year old but it wasn't forgotten. The
SVAR addon version included with the recent gretl 2024c release has
these related new features:
On Wed, Dec 27, 2023, 12:56 PM Sven Schreiber
<sven.schreiber(a)fu-berlin.de> wrote:
...
First, to specify the entire matrix as with the GUI as you requested.
Such a pattern matrix can now be given to SVAR_restrict as an
alternative to the old (and still supported) way. See the adjusted
documentation in the SVAR guide (pdf doc).
Secondly, I guess it would be nice to specify the restrictions not
just by their index positions in the matrix, but by using the
shock names (if they exist) and the variable names, like we
recently do with set identification restrictions in SVAR_SRplain,
for example. This might require a new function as an alternative
to SVAR_restrict, let's see.
Now there is such a new function, namely SVAR_namedrestrict, which
allows to do just this. Again, see the documentation. This functionality
is not reflected in the GUI, because we need shock/variable name pairs,
and it's not so obvious how that should be done with the limited layout
options that we have for hansl-based packages and addons.
cheers
sven
2:43 p.m.
Yes!
Both names are welcome.
Thanks for the update, sir.
I already noticed the update in the current version of Gretl.
However, we hope to see Gretl doing restrictions on the lags in VAR/ VECM
just as in JMulTi and Eviews and also possibly estimating the parameters
with 2stages, 3stages, gls, and ols just like in JMulTi.
Cheers.
On Tue, 29 Oct 2024, 2:08 pm Sven Schreiber, <sven.schreiber(a)fu-berlin.de>
wrote:
Am 28.12.2023 um 21:02 schrieb Olasehinde Timmy:
OK sir. Thanks for the response. Nevertheless, I would suggest that the
SVAR/SVEC GUI is updated to include the space for names of shocks just like
the space provided for indexing the irf to cumulate.
Regards
John
Hello Timmy (or John?) after quite some time,
this email thread is almost one year old but it wasn't forgotten. The SVAR
addon version included with the recent gretl 2024c release has these
related new features:
On Wed, Dec 27, 2023, 12:56 PM Sven Schreiber <sven.schreiber(a)fu-berlin.de>
wrote:
> ...
>
> First, to specify the entire matrix as with the GUI as you requested.
>
Such a pattern matrix can now be given to SVAR_restrict as an alternative
to the old (and still supported) way. See the adjusted documentation in the
SVAR guide (pdf doc).
Secondly, I guess it would be nice to specify the restrictions not just by
> their index positions in the matrix, but by using the shock names (if they
> exist) and the variable names, like we recently do with set identification
> restrictions in SVAR_SRplain, for example. This might require a new
> function as an alternative to SVAR_restrict, let's see.
>
Now there is such a new function, namely SVAR_namedrestrict, which allows
to do just this. Again, see the documentation. This functionality is not
reflected in the GUI, because we need shock/variable name pairs, and it's
not so obvious how that should be done with the limited layout options that
we have for hansl-based packages and addons.
cheers
sven
_______________________________________________
Gretl-users mailing list -- gretl-users(a)gretlml.univpm.it
To unsubscribe send an email to gretl-users-leave(a)gretlml.univpm.it
Website:
https://gretlml.univpm.it/postorius/lists/gretl-users.gretlml.univpm.it/
3:07 p.m.
Am 29.10.2024 um 15:43 schrieb Olasehinde Timmy:
Yes!
Both names are welcome.
Thanks for the update, sir.
I already noticed the update in the current version of Gretl.
However, we hope to see Gretl doing restrictions on the lags in VAR/
VECM just as in JMulTi and Eviews and also possibly estimating the
parameters with 2stages, 3stages, gls, and ols just like in JMulTi.
As a partial answer, notice that with the native Choleski-VAR
functionality in gretl you can indeed leave out some lags. This is
similar to what Eviews offered in the past (would need to check the
current state of affairs there). However, this does not allow you to
have different lag structures in the individual equations, and also it
is not supported by the SVAR addon.
If you want to restrict/shrink the parameter space more generally, I
would also recommend the Bayesian approach of the BVAR package (by Luca
Pedini and a little bit also by myself) as a practical tool. This is
still work in progress, but was recently updated to version 0.4 and
offers several popular choices of priors. In terms of shock
identification, only Choleski is supported so far - this will hopefully
change and be extended in the medium term.
cheers
sven
4:55 p.m.
Thanks for your response, sir. You always gave a brilliant response.
Please, pardon me as I ask this out of the box question. Is there any hope
that Gretl will support Global VAR model and/ or DSGE model in the nearest
future?
Cheers.
On Tue, 29 Oct 2024, 4:23 pm Sven Schreiber, <sven.schreiber(a)fu-berlin.de>
wrote:
Am 29.10.2024 um 15:43 schrieb Olasehinde Timmy:
>
> Yes!
> Both names are welcome.
> Thanks for the update, sir.
> I already noticed the update in the current version of Gretl.
>
> However, we hope to see Gretl doing restrictions on the lags in VAR/
> VECM just as in JMulTi and Eviews and also possibly estimating the
> parameters with 2stages, 3stages, gls, and ols just like in JMulTi.
>
As a partial answer, notice that with the native Choleski-VAR
functionality in gretl you can indeed leave out some lags. This is
similar to what Eviews offered in the past (would need to check the
current state of affairs there). However, this does not allow you to
have different lag structures in the individual equations, and also it
is not supported by the SVAR addon.
If you want to restrict/shrink the parameter space more generally, I
would also recommend the Bayesian approach of the BVAR package (by Luca
Pedini and a little bit also by myself) as a practical tool. This is
still work in progress, but was recently updated to version 0.4 and
offers several popular choices of priors. In terms of shock
identification, only Choleski is supported so far - this will hopefully
change and be extended in the medium term.
cheers
sven
_______________________________________________
Gretl-users mailing list -- gretl-users(a)gretlml.univpm.it
To unsubscribe send an email to gretl-users-leave(a)gretlml.univpm.it
Website:
https://gretlml.univpm.it/postorius/lists/gretl-users.gretlml.univpm.it/
11:56 a.m.
Am 26.12.2023 um 18:20 schrieb Olasehinde Timmy:
Dear Prof,
I am aware that the code 'SVAR_restrict(&x, "C", 1, 2, 0)' is to
inform Gretl of the nature of the restriction to estimate. I also know
that this has to be repeated for several restrictions like in the
model. However, I consider this to be rigorous especially when a large
matrix is involved. Although, I know how a matrix can be created and
used with the SVAR GUI, I don't know how it can be used with the
SVAR_restrict(&x, ) function.
Please, I need to be enlighten if this is possible or if I have to do
the imputation for each restriction.
Hello,
the short answer is no, it's currently not possible. We have always
thought it's not a big problem, since you typically use copy&paste. But
OK, I can see that when you have perhaps n=6 or so, then the needed
lines look a bit exaggerated.
I guess there are two things that would be desirable:
First, to specify the entire matrix as with the GUI as you requested.
(As a secret, you could in principle use the GUI_SVAR function also in a
script. But that is not recommended, as it is not designed for that, and
that's why it's not documented.) Technical note: Passing the entire
matrix to SVAR_restrict as an alternative argument might be implemented
using the very recent "numeric" meta datatype -- this will need some
testing but sounds like worth trying.
Secondly, I guess it would be nice to specify the restrictions not just
by their index positions in the matrix, but by using the shock names (if
they exist) and the variable names, like we recently do with set
identification restrictions in SVAR_SRplain, for example. This might
require a new function as an alternative to SVAR_restrict, let's see.
thanks
sven
8:02 p.m.
OK sir. Thanks for the response. Nevertheless, I would suggest that the
SVAR/SVEC GUI is updated to include the space for names of shocks just like
the space provided for indexing the irf to cumulate.
Regards
John
On Wed, Dec 27, 2023, 12:56 PM Sven Schreiber <sven.schreiber(a)fu-berlin.de>
wrote:
Am 26.12.2023 um 18:20 schrieb Olasehinde Timmy:
Dear Prof,
I am aware that the code 'SVAR_restrict(&x, "C", 1, 2, 0)' is to
inform
Gretl of the nature of the restriction to estimate. I also know that this
has to be repeated for several restrictions like in the model. However, I
consider this to be rigorous especially when a large matrix is involved.
Although, I know how a matrix can be created and used with the SVAR GUI, I
don't know how it can be used with the SVAR_restrict(&x, ) function.
Please, I need to be enlighten if this is possible or if I have to do the
imputation for each restriction.
Hello,
the short answer is no, it's currently not possible. We have always
thought it's not a big problem, since you typically use copy&paste. But OK,
I can see that when you have perhaps n=6 or so, then the needed lines look
a bit exaggerated.
I guess there are two things that would be desirable:
First, to specify the entire matrix as with the GUI as you requested. (As
a secret, you could in principle use the GUI_SVAR function also in a
script. But that is not recommended, as it is not designed for that, and
that's why it's not documented.) Technical note: Passing the entire matrix
to SVAR_restrict as an alternative argument might be implemented using the
very recent "numeric" meta datatype -- this will need some testing but
sounds like worth trying.
Secondly, I guess it would be nice to specify the restrictions not just by
their index positions in the matrix, but by using the shock names (if they
exist) and the variable names, like we recently do with set identification
restrictions in SVAR_SRplain, for example. This might require a new
function as an alternative to SVAR_restrict, let's see.
thanks
sven
_______________________________________________
Gretl-users mailing list -- gretl-users(a)gretlml.univpm.it
To unsubscribe send an email to gretl-users-leave(a)gretlml.univpm.it
Website:
https://gretlml.univpm.it/postorius/lists/gretl-users.gretlml.univpm.it/
54
days inactive
362
days old
6 comments
2 participants
participants (2)
-
Olasehinde Timmy -
Sven Schreiber