In the book ‘Bayesian Analysis with Stata’ I described how we can fit a Bayesian model using Stata to control WinBUGS and OpenBUGS and last year, in this blog, I showed how the same approach could be used to control another BUGS-like program called JAGS. So, currently, we have a choice of three programs for fitting Bayesian models by Gibbs sampling, each of which can be controlled from Stata using almost identical Stata commands.
Now I want to extend the approach to Stan (http://mc-stan.org/), another program for Bayesian model fitting that can be downloaded for free from the internet. WinBUGS, OpenBUGS and JAGS all have very similar syntax, so it is easy to control them by setting an option in one of my wbs commands. Stan is very different and so we have to decide whether to stretch the existing Stata commands to accommodate Stan, or to provide a new set of commands.
My instinct is to accommodate Stan within the existing framework if at all possible, because my image of the typical Stata user is of someone who does not care what Stan does with their model; they just want the answer. So, part of the aim is to hide the complexity and to emphasise the similarities between calling WinBUGS and calling Stan, in the sense that they can fit the same Bayesian models to the same data and, hopefully, provide equivalent answers, albeit by using different samplers. Having said that, I am sure that the Stan team would want to emphasise the fact that Stan can tackle problems that would overwhelm WinBUGS.
Let’s recap the method that we have established for working with the BUGS-like programs. We set up 4 text files,
a) The model file: describing the model in BUGS-like syntax
b) The data file: providing the formatted data in an R-like style
c) The initial values file: providing the initial values for the Gibbs samplers
d) The script file: providing our choices for controlling the MCMC run
The script file is sent to the BUGS-like program and it returns the simulations in a coda-formatted text file.
To help in this process there are a series of Stata commands all beginning wbs
wbsmodel: copies the model description from the Stata do file to the model file
wbslist: writes data and initial values in R-like format
wbsscript: prepares the script file
wbsrun: runs the script file
wbscoda: reads the results into Stata
Stan does not quite fit this pattern;
a) The syntax for describing the model is different
b) The data formatting is, however, in R-style and so is quite similar, especially to JAGS
c) We don’t need to provide initial values
d) The model and data are turned into C++ code, combined with standard Stan modules and linked into a problem-specific compiled program
e) There is no script file as such, but rather the compiled program is run directly by the operating system with a series of command line arguments that control the estimation
f) Because the compiled program is sent directly to the operating system, we will have to prepare different command files for linux and for windows
Now let’s look on the positive side,
a) The model syntax might be different but that is not our concern, whether the user wants to run WinBUGS or Stan they have to learn the syntax for that program. Our only concern is to write the user’s code to a text file, which is the same process for both programs and could be accomplished with wbsmodel
b) The data formatting is similar to JAGS so there should not be many changes required to make wbslist work for Stan
c) Scripting is the real difference. Instead of a set of batch commands that we send to WinBUGS, we must prepare a Windows batch file that we send to the operating system.
d) When we prepare the batch file rather than the script file with wbsscript, we will run into problems because Stan does not use Gibbs sampling, so the nature of the options that are required is different and we will have to provide many more options.
e) Stan writes the data in comma delimited (.csv) format rather than coda format; this ought to make reading them into Stata more straightforward, at least it would had the developers not decided to pack other information into the results file. We will need to extract information from the .csv file, rather than read it directly.
These modifications raise the issue of the naming of the Stata commands. wbsmodel was a reasonable name when it was used for creating the WinBUGS model file but perhaps something more generic would be better if it is to work for WinBUGS, OpenBUGS, JAGS and Stan and maybe with other programs in the future. Despite this, I will not change names for the time being.
We might note in passing that Stan’s approach of compiling a problem-specific program is much the same as the approach that I adopt in mcmcrun when the user writes the program for calculating the log-posterior in Mata. Except, of course, I only provide a limited set of samplers designed for Gibbs sampling, while Stan uses completely different samplers. Perhaps at some stage, the Stan samplers could be re-written in Mata.
Now there is a further problem due to the fact that Stan compiles C++ code to create really fast problem-specific programs. That is, we need a C++ compiler or it will not work. If you use linux, this is not a problem because a compiler called gcc is part of the basic operating system; Windows users, including my typical Stata user, are not so lucky. So before we can run anything under Windows, we will have to install gcc and another program called make.
There are two ways to obtain gcc and make, either we install a free program called Cygwin which provides Windows with a terminal (command prompt window) with linux-like properties or we install a free program called Rtools which is a part of the R software intended for creating R packages; this too contains gcc and make.
What you need to do in order to install Stan is clearly set out in the Stan manuals, one of which is 80 pages long, while the other is about 500 pages long. The installation instructions assume quite a bit of prior knowledge. I suspect that some people would give up at this point and stick with WinBUGS. So, I will dedicate my next posting to describing the installation of Stan. Then I will return to the issue of controlling the program from within Stata.
In future postings I will explain the samplers that Stan uses and present some examples of analysing data by calling Stan from within Stata.
Are you aware of this? https://github.com/stan-dev/statastan/tree/alpha-test
Thank you for pointing this out. I did not know of this particular link but I had heard that a group in the US had a grant for developing a way of calling Stan from Stata. After I have finished describing my own approach, I’ll check out this link and contrast the various ways of running Stan.