1:59 p.m.
Hi,
with respect to analyzing SVARs I've taken a relatively close look at
the (AFAIK quite recent) 'vars' package in R, and also read Jack's doc
on his preliminary gretl svar functions (well I also looked a little at
the functions themselves).
First of all, R's 'vars' package is quite complete and nicely
documented. So my first reaction is: don't bother with reinventing the
wheel yet again and point interested users to that package. I could also
write some wrapper functions (packages) to access them from the gretl side.
Two possible caveats:
1. Bootstrapping the impulse responses appears to be very slow in
R-vars. I compared (roughly) the same setup in Jmulti and in R-vars, and
Jmulti (Gauss in the background) was at least 10 times faster than
R-vars. (Admittedly I ran Jmulti on Windows on a different computer, but
the hardware specs are not too different and 9 seconds vs. 3 minutes is
drastic enough for me.)
2. R-vars relies on R-urca from the same author to specify the VECM (for
SVEC modeling), and AFAICS in R-urca it's not possible to place such
elaborate restrictions on the cointegration relations as gretl (remember
the Boswijk/Doornik paper) or Jmulti can do.
@1: In general I would tend to think it's better to help R-vars get
faster instead of developing a competing implementation. (Better to
collaborate than to multiply the needed efforts.) But I don't know if
that's feasible, I really don't know much about R or about the
implementation in R-vars. Also, since Jack has already done quite an
amount of work on this, gretl wouldn't start from scratch, so maybe
there wouldn't be that much duplicate effort (not counting the sunk
effort, of course).
@2: For me this seems a more serious issue, but that's of course driven
by my personal preferences. In my view modeling the cointegration space
properly for non-trivial setups often requires placing restrictions on
the cointegration space. So the fact that this feature is missing from
R-vars could be a reason to do a gretl-native implementation. (Not sure
wether native would necessarily mean c-coding though, pure gretl may be
enough?) OTOH, it could be argued that this is very specialized and
people should stick to Jmulti (or Anders Warne's SVAR program which
actually does much more than that). Jack, AFAICS your functions also do
not allow to do restricted VECMS, right?
Comments?
thanks,
sven
5:27 p.m.
Sven Schreiber schrieb:
Hi,
with respect to analyzing SVARs I've taken a relatively close look at
the (AFAIK quite recent) 'vars' package in R, and also read Jack's doc
on his preliminary gretl svar functions (well I also looked a little at
the functions themselves).
First of all, R's 'vars' package is quite complete and nicely
documented. So my first reaction is: don't bother with reinventing the
wheel yet again and point interested users to that package. I could also
write some wrapper functions (packages) to access them from the gretl side.
Two possible caveats:
1. Bootstrapping the impulse responses appears to be very slow in
R-vars. I compared (roughly) the same setup in Jmulti and in R-vars, and
Jmulti (Gauss in the background) was at least 10 times faster than
R-vars. (Admittedly I ran Jmulti on Windows on a different computer, but
the hardware specs are not too different and 9 seconds vs. 3 minutes is
drastic enough for me.)
2. R-vars relies on R-urca from the same author to specify the VECM (for
SVEC modeling), and AFAICS in R-urca it's not possible to place such
elaborate restrictions on the cointegration relations as gretl (remember
the Boswijk/Doornik paper) or Jmulti can do.
@1: In general I would tend to think it's better to help R-vars get
faster instead of developing a competing implementation. (Better to
collaborate than to multiply the needed efforts.) But I don't know if
that's feasible, I really don't know much about R or about the
implementation in R-vars. Also, since Jack has already done quite an
amount of work on this, gretl wouldn't start from scratch, so maybe
there wouldn't be that much duplicate effort (not counting the sunk
effort, of course).
@2: For me this seems a more serious issue, but that's of course driven
by my personal preferences. In my view modeling the cointegration space
properly for non-trivial setups often requires placing restrictions on
the cointegration space. So the fact that this feature is missing from
R-vars could be a reason to do a gretl-native implementation. (Not sure
wether native would necessarily mean c-coding though, pure gretl may be
enough?) OTOH, it could be argued that this is very specialized and
people should stick to Jmulti (or Anders Warne's SVAR program which
actually does much more than that). Jack, AFAICS your functions also do
not allow to do restricted VECMS, right?
Comments?
thanks,
sven
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
Actually I was waiting for some more qualified responses to Sven's draft
than mine, but nobody else seems really interested in the implementation
of a SVAR function in gretl, maybe.
I would be in favor of the implementation, regardless of the way which
is chosen. I checked once the R function and it seemed quite complete
but I had never the time to bother with R. In the past I have chosen
JMulti instead which is really nice but does not run under my ubuntu
system(s) for some reason. So I have to work with it within the virtual
machine.
If a wrapper function for gretl is not hard to program this could be a
first step to implement SVAR. Maybe it is possible to get in contact
with the developer of the R function package and to ask him/her for a
collaboration with gretl on this point. Maybe s/he also interested to
improve the speed of bootstrapping and to implement restricted VECMs.
Best,
Artur
7:50 p.m.
Em 10 de janeiro de 2010 Artur T. <artur.tarassow(a)googlemail.com> escreveu:
Actually I was waiting for some more qualified responses to Sven's draft
than mine, but nobody else seems really interested in the
implementation
of a SVAR function in gretl, maybe.
Sven and Artur, I'm really interested in implementation of a SVAR in Gretl.
I think it will be great for us!
Best,
Henrique
3:48 p.m.
On Thu, 7 Jan 2010, Sven Schreiber wrote:
Hi,
with respect to analyzing SVARs I've taken a relatively close look at
the (AFAIK quite recent) 'vars' package in R, and also read Jack's doc
on his preliminary gretl svar functions (well I also looked a little at
the functions themselves).
[...]
My take on SVARs: if you want to do Structural VARs with free software,
the possible alternatives that come to my mind are:
1) use R + urca + vars
2) use jMulti
3) use my collection of scripts
I am deliberately excluding A. Warne's program since it isn't free
software (which is a shame, since it's very very good).
My preference goes to alternative 3 (astonishing, isn't it?). The only 2
people who have seen my scripts so far are Allin and Sven, since I don't
consider them ready for prime time yet. However, since I've wanted to work
on these for a long time, but never did, I'm putting them on a location
they can be downloaded from:
http://www.econ.univpm.it/lucchetti/gretlSVAR.tgz. Hopefully someone else
will find them useful and improve them. As they say, "release early,
release often". When, in the future, we find that the algorithms are
sufficiently robust and reliable, we may think about translating them to C
and incorporating SVARs into gretl proper.
Why not jMulti? Well, because despite being a very good package when it
comes to the algorithms, I'm sorry to say it's pretty much dead. A Linux
version hasn't been released for ages, and all the progress I've seen for
a while was some occasional bugfix. Plus, I'm not exactly enthusiastic
about the combination of gauss (or R) for number crunching, java for the
GUI and postscript for the output (too many things that can go wrong).
Last but not least, it's not scriptable.
Why not R, then? To begin with, I think our own implementation of VARs +
cointegration-related stuff is better. Next, there's the usual gripe I
have with R: either you work with it all the time, or its syntax is, let's
say, unpleasant. I like to think that gretl's now excellent interface to R
allows us to use R as a fallback tool. But in the long-term, I'd rather
use gretl as much as possible.
For the brave souls who will try to get some work done with my functions:
I've tried to test pretty much everything to the best of my skills, except
for bootstrapping, which is still untested and probably contains hordes of
bugs (as opposed to the odd bug here and there in the rest of the
package). However, the tarball also contains a pdf file which will guide
you through the basic syntax and is the nearest thing to proper
documentation that I can provide.
PS: Sven, with my functions you CAN do restricted SVECMs. The \beta matrix
is one of the inputs, and the function by itself doesn't care about the
way it was estimated (assistance by superconsistency is gratefully
acknowledged).
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
9:26 p.m.
Riccardo (Jack) Lucchetti schrieb:
My take on SVARs: if you want to do Structural VARs with free software,
the possible alternatives that come to my mind are:
1) use R + urca + vars
2) use jMulti
3) use my collection of scripts
I am deliberately excluding A. Warne's program since it isn't free
software (which is a shame, since it's very very good).
That's a bit harsh because the code is GPLed, "only" the platform
isn't.
Does anybody have an idea how much work it would be to adapt it to
run successfully in Octave (graphical stuff aside)?
Why not jMulti? Well, because despite being a very good package when it
comes to the algorithms, I'm sorry to say it's pretty much dead. A Linux
version hasn't been released for ages, and all the progress I've seen
for a while was some occasional bugfix. Plus, I'm not exactly
enthusiastic about the combination of gauss (or R) for number crunching,
java for the GUI and postscript for the output (too many things that can
go wrong). Last but not least, it's not scriptable.
Well as you may know because you mention R, the long-term plan by the
developer (Markus) indeed is to replace the Gauss engine with R code.
Then you would also get R graphics. (And BTW, the Gauss runtime engine
on Linux is buggy as I have experienced myself, so that's also a reason
why no current Linux version.) I have started to try to help with the
transition, but got stuck fairly early on because the structure of the
Gauss code in Jmulti needs "getting used to". (It's very well tested
though.) And I was basically trying to port _from_ a language I don't
know much about _to_ a language I don't know well either. So I guess
it's a call to the "community" -- if you want Jmulti to be alive you
need to do something about it. (No not you personally Jack.)
Why not R, then? To begin with, I think our own implementation of VARs +
cointegration-related stuff is better. Next, there's the usual gripe I
have with R: either you work with it all the time, or its syntax is,
let's say, unpleasant. I like to think that gretl's now excellent
interface to R allows us to use R as a fallback tool. But in the
long-term, I'd rather use gretl as much as possible.
Yes.
PS: Sven, with my functions you CAN do restricted SVECMs. The \beta
matrix is one of the inputs, and the function by itself doesn't care
about the way it was estimated (assistance by superconsistency is
gratefully acknowledged).
Ah very good, I should have noticed that. I guess that could be another
reason for working on the gretl code instead of the other solutions.
thanks,
sven
12:37 p.m.
On Mon, 11 Jan 2010, Sven Schreiber wrote:
Riccardo (Jack) Lucchetti schrieb:
That's a bit harsh because the code is GPLed, "only" the platform
isn't.
Does anybody have an idea how much work it would be to adapt it to
run successfully in Octave (graphical stuff aside)?
Ok, I apologise for the choice of words. However, the matlab requirement
seems pretty stringent to me: I've heard that the Dynare port to octave
was a fairly major piece of work (and note that Dynare has a _team_
working on it). I can't say anything first-hand, though.
> Why not jMulti? [...]
Well as you may know because you mention R, the long-term plan by the
developer (Markus) indeed is to replace the Gauss engine with R code.
[...]
Why not try to involve Markus Krätzig into gretl instead?
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
5475
days inactive
5480
days old
6 comments
4 participants
participants (4)
-
Artur T. -
Henrique -
Riccardo (Jack) Lucchetti -
Sven Schreiber