I would like to propose TuringRegressions.jl - a more fully featured alternative to TuringGLM.jl offering much more of what brms does in R, most notably:
correlated random effect slopes, i.e. full support for formula terms such as (1|g), (1+x|g), (1+x|g&f)
internal standardisation of model fit, giving accurate and fast results vs brms benchmarks
easy extraction of parameter values
tidy model summaries
prediction including on new data
StatsAPI integration - all TuringRegressions are StatsAPI.RegressionModels (as far as possible)
exportable and adaptable Turing model code
I haven’t submitted it to the registry yet, since I wanted to gather some feedback first:
Would people find this package useful?
Is the API sensible? Would people like to see any changes?
Is the scope too broad?
It’s my first time doing this, and I might have bitten off more than I can chew - so all and any feedback would be very welcome! Even more welcome would be a review, though I realise that would be a lot to ask.
AI usage: I used Claude to help with the random-effects implementation around parameter reshaping and standardisation, as well as (especially) for writing the tests, benchmarks (entirely), and docstrings. I’ve reviewed the code, and the main verification comes with a suite of fits matched against brms outputs.
One thing that I would do is create a proper docs site (e.g., with Documenter.jl). I do like a thorough README.md that serves as a kind of cheat sheet, but having a nice docs page is also helpful.
I am not an expert in this domain, but I’ve always felt slightly uneasy about these kinds of packages that make specifying Bayesian hierarchical models quick and easy. When I first started learning Bayesian modeling, what I liked was the fact that it forced you to really think through all the priors and how to specify them properly, so relying on default priors hasn’t ever really sat well with me. I like that “[p]riors are somewhat customisable,” but I really prefer to have full control over the priors.
Please don’t take this as negative feedback, I really want to be constructive here - and again, welcome to the amazing Julia community!
Super cool project! Some of the JuliaBayes people have been discussing similar ideas over on Julia’s Slack channel – if you’d like, feel free to join #bayes there. We’d be happy to talk to you about your project and our ideas! It would be great to join forces.
Thank you very much everyone for the welcome and comments!
@mthelm85 I’ll absolutely make a proper docs site before releasing anything, thanks. And prior customisability is a good point, it would be a fair bit of work but it’s definitely a to-do.
@parn4q This started as a fork of TuringGLM.jl but in the end incorporating random effects, standardisation and prediction meant that there was very little left of the original package, object), so I made it a standalone project.
@simonsteiger I was wondering where the community for this was - and I’m glad to have found it! I’ll join and make a post in the Slack.
will there be a kwarg to say if a covariates should be standardized?
I may have more but this is it for now. The code is easily readable, which is nice. I agree that have customizable priors is important, but you’re starting off strong by making the easier cases work. I LOVED brms in R, and I love turing. It has grown tremendously over the years.
Thank you for your comments @parn4q ! On those questions:
Yes, you can switch ADtypes, all kwargs to fit!() are passed to Turing.sample() so you can adjust anything. By default, it’s AutoForwardDiff() unless it’s a random-effects model, in which case it’s AutoReverseDiff() since some experimentation found that was typically faster.
All covariates are standardised internally, then coefficients are un-standardised back out, so any data can be passed (including when predicting on new data). I haven’t added a kwarg to turn that off, since I found it meant that brms/GLM results couldn’t be replicated, but it could be something to add.
Just want to say I agree with this. I think DynamicPPL and others are simple enough to use directly, perhaps unlike Stan so there was a need for brms. Maybe AI is making Stan coding easier so the need for brms is decreasing.
