and in reply to the general architecture of bayesmh:

I think there is this persistent problem that users cannot just allocate combinations of data, matrices and parameters to whatever they want. Stata has introduced the idea of “substitutable expressions” a while back, which takes macro substitution and extends it to having an expression inside an otherwise non-declarative line of code.

(Stata, for those unfamiliar, is not a functional or object-oriented language but an imperative scripting language. Underneath, there is a somewhat-lower-level OOP language called Mata.)

But substitutable expressions can’t do everything. Notably, we can’t have a missing value in one datum and allocate a substitutable expression to it (allowing for missing data models). StataCorp’s conception of a Bayesian model is that it is one of the existing models (likelihoods), plus priors. I think this will keep tripping up serious Bayesian model builders, who often want to go beyond that concept.

I gave a talk at the London users’ group in 2021 about Bayesian software and Stata’s strengths and weaknesses, and to solve this problem, I suggested that Stata would need to develop its own probabilistic programming language like BUGS/JAGS or Stan. From breakout room discussion including StataCorp personnel, I got the impression that this was already on their radar. That doesn’t mean it will happen, but it is being thought about.

So, for BMA in Stata, we can probably make workarounds but there will still have to be a big reconfiguration of the Bayesian provision. Personally, I would rather wait for a future flexible Bayesian system within Stata than invest in workarounds that might be short-lived.

• This reply was modified 2 years, 10 months ago by Robert Grant.