BVAR (Bayesian VAR)

[EViews Gareth]

This thread is about the BVAR Add-in that performs a Bayesian VAR estimation.

Change Log

• 2010/04/08 - Initial release
• 2010/04/09 - Better error handling for cases where there are NAs in the data or sample breaks
• 2010/04/12 - Removed Nu, and fixed bug introduced by previous fix for sample breaks.

A new version of this Add-in has been released (2010/11/11), and a new forum thread has been created:
http://forums.eviews.com/viewtopic.php?f=23&t=3295

[EViews Gareth]

Posted update that handles NAs and sample breaks better. Internal NAs or sample breaks will issue an error. NAs at the ends will cause the sample to be shrunk.

[donihue]

Dear Gareth,

Just a note to thank you greatly for having included BVARs in your list of Add-ins. You have made a large number of central bank users very happy indeed!

If DSGEs were also to find their way onto your list, we would reach Nirvana ...

Regards
Donihue

[EViews Gareth]

I was actually inspired by one of your previous posts - I read it and thought "I wonder if there is an R package that does it?", there was, and adding an EViews front-end to an R package is relatively simple (with a bit of practice), so making the BVAR add-in only took an afternoon or so.

[donihue]

Dear Gareth,

Further to this, in a quick test, using all the default settings, I do not find any output in the IRF tables. I have used MSBVAR as a standalone in the past without such problems. Has the porting to EViews somehow cleared these entries?

Regards
Donihue

[EViews Gareth]

Looks like something went wrong during the calculation of the BVAR - notice the log-likelihood is NA.

If you post your workfile, I'll see if I can figure out what is going on.
Although if you have some familiarity with MSBVAR, you might like to take a look yourself - if you go to the add-in folder for the BVAR add-in (probably "my documents\eviews addins\bvar") and then open up the bvar.prg program, and edit the first line so that it says !debug=1, then go to the bottom of the program and comment out the XCLOSE command, and save, when you run the Add-in, you should see the R Log open and see any errors that R reports.

Which points out I need to change that program so that !debug=1 automatically disables the XCLOSE command

[donihue]

Gareth,
As you saw, R could not find a solution to the model. Odd, since the full model runs fine as a standard VAR and as a BVAR under RATS ...
I found that when using a restricted version of the model, dropping the price variables, the routine works.
So (happily) it does not seem to be a "porting" problem, but a model-specific one. I will follow-up in R using your suggestion.
Regards
Donihue

[donihue]

Gareth,

Having now looked into the documentation for the szbvar routine in MSBVAR, I find that nu is supposed to equal m+1, where m is the number of ts objects. Yet I find that whenever I run the add-in routine, I obtain nu=3. Hence, whenever I use 4 or more ts objects, the result is

"> xget(name = _MPOST01) BVAR$marg.post
R (for 'BVAR$marg.post') returned an error: unexpected fatal error in back-end implementation. release the object!."

(Curiously, it works when m=3 and nu also =3; but not if m=4 or more)

Also, the routine automatically appends the instruction "IF SMPLSER=1 AND" in the sample box but AFTER the sample, so it is always necessary to edit the sample to remove this addition.

Regards
Donihue

[donihue]

Gareth,

Yet further to this, perhaps it would be better not to allow "nu" to be set in the add-in box, given that it is suposed always to be equal to m+1.
The problems I reported earlier disappear when I follow this convention in the add-in box.

Regards
Donihue

[EViews Gareth]

Nu was a last minute addition that I probably didn't test as well as I should. I'll remove it. I'll also investigate the sample issue.

Thanks for the suggestions - my experience at both R and BVars is fairly limited.

[EViews Gareth]

New update posted addressing samples and Nu

[donihue]

Thanks very much Gareth.

Just tested the new version. Unfortunately, a similar sample problem arose - see photo below.

I also noticed that MSBVAR will work with nu >= m+1 (but not <) so perhaps an option for nu could still be left in, but coded so that it has to meet the >= m+1 condition

Regards
Donihue

[EViews Gareth]

I'll contemplate Nu tomorrow.

I fixed a bug with the samples, but I'm not sure I follow your bug. That box simply gets filled out with the workfile sample when you run the add-in.

It might be that after a debugging run, or a run where R failed, the workfile sample is left in a bad state so that when you re-run the add-in, that box gets filled with junk.

[donihue]

Gareth,

Regarding the sample box, I think you are right - the problem seems to arise only when something goes wrong in R.

Another small point: the add-in box does not seem to retain the names of the endogenous variables from one estimation to the next (unlike, for example, the VAR dialogue); it would be nice if it did ...

Finally, szbvar allows for exogenous variables (in the matrix z). The default is z=NULL, but it does not have to be. Perhaps in a future revision, the add-in could also permit the use of exogenous variables?

Regards
Donihue

[EViews Gareth]

Remembering the variables is a little tricky to do in an add-in.

The version of msbvar I was working with does not yet support exogenous variables (although the docs say they will in the future)