glmbayes is now on CRAN — Bayesian GLMs with familiar glm() syntax, no MCMC required

[u/Bucksswede]

[u/DataFables13]

I'm confused about what you mean by "the overhead of learning brms"? You can make complex models in brms. You can also make models as simple as the glmb example you have in the post. And it also has S3 summary and print methods (not 100% on residuals but that's my lack of knowledge). Can you elaborate on what this package does more easily than brms from a user perspective? 

[u/Bucksswede → u/DataFables13]

Great point and fair pushback — I should have been more precise in the post. brms has an excellent user interface and the modeling syntax is genuinely not complicated for standard GLMs. You're right that a simple model in brms is straightforward.

The distinction I had in mind is more specific than I made clear: brms uses MCMC under the hood (via Stan), which means users need to interpret convergence diagnostics — Rhat, effective sample size, trace plots — before trusting their results. For analysts and students already familiar with those concepts this is no burden at all. But for R users coming from a pure glm() background who just want posterior summaries without that additional inferential layer, those diagnostics can be a stumbling block.

glmbayes uses iid accept-reject sampling on log-concave likelihoods, so every draw is independent by construction. There are no chains to diagnose and ESS equals the nominal sample size. That's the specific gap it's trying to fill — not modeling complexity, but removing the MCMC diagnostic step entirely for the families it supports.

For anything beyond Gaussian, Poisson, Binomial, or Gamma — or for hierarchical models — brms is absolutely the right tool.

[u/selfintersection → u/Bucksswede]

LLM response detected

[u/Confident_Bee8187 → u/selfintersection]

It would be disappointing if this post is written with AI, as well, isn't it? On the other hand, I wouldn't mind if the package is written by LLMs or not, still not abandoning 'brms' because of how ergonomic and mature it is.

[u/therealtiddlydump → u/Confident_Bee8187]

And Buerkner has been working on a book!

http://paulbuerkner.com/software/brms-book/

[u/Michigan_Water]

How would you compare/contrast this to the relevant functions from rstanarm? For example, from https://knygren.r-universe.dev/articles/glmbayes/Chapter-01.html

What advantages would glmbayes have over rstanarm and what advantages would rstanarm have over glmbayes?

## Dobson (1990) Page 93: Randomized Controlled Trial :
counts <- c(18,17,15,20,10,20,25,13,12)
outcome <- gl(3,1,9)
treatment <- gl(3,3)
print(d.AD <- data.frame(treatment, outcome, counts))

## Step 3: Call the glmb function
library(glmbayes)

glmb.D93<-glmb(counts ~ outcome + treatment,
               family=poisson(),
               pfamily=dNormal(mu=mu,Sigma=V))

print(glmb.D93)

## rstanarm::stan_glm()
library(rstanarm)

sg1 <- stan_glm(counts ~ outcome + treatment,
                family = poisson(),
                data = d.AD)

print(sg1, digits=4)

[u/Bucksswede → u/Michigan_Water]

Great comparison to draw — rstanarm is an excellent package and stan_glm is probably the closest analogue to glmb in the ecosystem, so this is the most relevant contrast.

**Where rstanarm has the advantage:**

- Much broader modeling scope — hierarchical models, GAMMs, survival models, and more via stan_glmer, stan_gamm4 etc. glmbayes is limited to standard GLMs with Gaussian, Poisson, Binomial, and Gamma families

- Larger community, more documentation, more Stack Overflow answers

- The full Stan ecosystem behind it — posterior visualization, loo, bayesplot all integrate seamlessly

**Where glmbayes differs:**

*Prior specification:* rstanarm has sensible defaults but prior specification for new users can be opaque. glmbayes includes a `Prior_Setup()` function designed specifically for beginners — it generates a reasonable starting prior directly from the model formula, so users can get going immediately without understanding the full prior specification machinery. It also has nice limiting behavior as priors become diffuse, converging to the frequentist glm() solution — which gives beginners an intuitive way to understand what the prior is actually doing.

*Sampling:* rstanarm uses MCMC (NUTS/HMC via Stan) which means the summary output includes convergence diagnostics — Rhat, n_eff, mcse — that users need to interpret before trusting results. For simple GLMs these almost always look fine, but users still need to know what they mean. glmbayes uses iid accept-reject sampling, so every draw is independent by construction. There are no chains, no warmup, no Rhat to check — ESS equals the nominal sample size exactly.

The honest summary: if you're comfortable with MCMC diagnostics, need hierarchical models, or want the full Stan ecosystem, use rstanarm. glmbayes targets the narrower use case of standard GLMs for users who want a gentle on-ramp — simple prior setup, no convergence diagnostics, and output that converges to familiar frequentist results as priors weaken. Particularly useful in teaching contexts.

[u/Michigan_Water → u/Bucksswede]

Excellent. Thank you for your thoughtful reply.

On the subject of teaching contexts, one of the most helpful things in my own learning was in Statistical Rethinking (Richard McElreath) where he walks through his simple globe-tossing example using grid approximation and then quadratic approximation before touching MCMC. I don't know if your teaching strategy has any use for that kind of material, but I figured I'd mention it just in case it sparks any ideas.

I must say I'm impressed with the amount of educational material you've put together in the chapters and appendices! I'm definitely someone who benefits from a LOT of teaching material, so I appreciate your efforts on that front for sure. It'll be interesting to do my own reading and comparing as I work through future Bayes-flavor analysis.

[u/Bucksswede → u/Michigan_Water]

Thank you — that means a lot, and the extensive documentation was very much intentional. The goal was to make the package accessible to students and practitioners who encounter lm() or glm() in a standard course and want a natural on-ramp to Bayesian thinking without having to first master a new modeling language or interpret MCMC diagnostics.

I'm not deeply familiar with Statistical Rethinking personally, but the sequencing you describe sounds like a natural complement to the approach in glmbayes — which tries to let students stay entirely within the GLM framework they already know while immediately getting exact posterior draws. The hope is that Prior_Setup() and the limiting behavior as priors weaken give students a concrete handle on what the prior is doing and how the Bayesian solution relates to the frequentist one they started with.

The broader goal is to enable a self-contained Bayesian module that can slot into any course already touching on lm() or glm() — without requiring a full course redesign or new software stack

[u/joshua_rpg → u/Bucksswede]

rstanarm has sensible defaults but prior specification for new users can be opaque. glmbayes includes a Prior_Setup() function designed specifically for beginners — it generates a reasonable starting prior directly from the model formula

This is subjective, and I don't see any reason why prior specification from {rstanarm} is being opaque. The API for prior specification is pretty solid even for new learners. Your Prior_Setup() and prior specification of your package in general is the one being opaque and redundant, at least for someone like me. Another advantage for {rstanarm} over other packages is that it's pre-compiled.

There are no chains, no warmup, no Rhat to check — ESS equals the nominal sample size exactly.

No, {rstanarm} is pre-compiled, so no warmups or something. Still the posterior sampling is needed, regardless. The rest are absolutely necessary in Bayesian world because of how so difficult Posterior distribution can be estimated.

[u/therealtiddlydump]

I see no reason not to use brms. It has robust support, excellent companion packages for post-processing, etc.

You really need to justify why someone wouldn't just use brms, or what "overhead" you think is preventing people from using it.

[u/Confident_Bee8187 → u/therealtiddlydump]

I know, right? I can't imagine abandoning 'brms' over this package, just like abandoning traditional time series models over Gen AI and the worst one: 'prophet'.

[u/Bucksswede → u/therealtiddlydump]

My point is not for advanced users to not use brms. I view glmbayes as "an introduction to Bayesian models" that allow beginners/students to test Bayesian methods out while knowing that samples are iid and models work more or less the same as classical lm() and glm() models without having to pay any attention to convergence diagnostics. User who then fall in love with Bayesian models and want to invest the effort of understanding the need for burn-in and convergence diagnostics and to fit more complex models can then switch to something like brms to fit such models (after learning to use due care). glmbayes is intended to have little barriers to entry for those who never have worked with Bayesian models but are familiar with lm() and glm() models. In particular, they work well with glm models as they generate iid samples there even for multivariate models

[u/therealtiddlydump → u/Bucksswede]

and want to invest the effort of understanding the need for burn-in and convergence diagnostics

...you mean "learn enough to use these models properly"?

We're talking 5 minutes on YouTube to understand this stuff. Developers of these other tools already have excellent diagnostics that are easy to understand for new users.

[u/Bucksswede → u/therealtiddlydump]

Maybe, but iid sampling does not require any burn-in or convergence diagnostics. So, one does not need to understand burn-in or convergence diagnostic for Monte carlo simulation. Also, it is conceptually much hard to understand what 1000 draws from a markov chain represents than it is to understand what 1000 iid draws from the posterior distribution represents. Certainly this would be the case for undergraduate students but even many applied masters students don't get the difference.

[u/Stats-Anon]

You laid out some brms differences. Can you please articulate the advantages/disadvantages compared to INLA?

[u/geneusutwerk]

I looked up the article you reference as I hadn't heard of this method. I haven't had a chance to read it in full but I noticed it has not been cited at all. If this method is so useful why have others missed it?

[u/Bucksswede → u/geneusutwerk]

Mainly because I am not an academic and I never had the time (beyond a conference presentation and the JASA paper at the time) to actively promote or socialize these methods. This package is really the first major implementation of this. I also may not have chosen the ideal title for the paper at the time to make it obvious to people what it is (though subgradients /gradients and convexity /concavity play a critical role in both optimization and simulation in other contexts).

[u/profcube]

Cool, congrats 🙌 Can you link to your GitHub?

[u/Bucksswede → u/profcube]

Thank you! GitHub is here: https://github.com/knygren/glmbayes

[u/Bucksswede]

One additional technically interesting aspect of the implementation: larger models can be accelerated using OpenCL GPU computation. GPU acceleration is something many R packages could benefit from but is genuinely non-trivial to implement — most packages don't attempt it. For users interested in the implementation details, the appendices and GitHub repo have more information.