A new preprint on validating that your #Bayesian model and/or sampling algorithm is working correctly: https://arxiv.org/abs/2211.02383
A thread: #Statistics #Stan 1/
Remote
Martin Modrák
@modrak_m@fediscience.org
mastodon 4.6.9Bioinformatics, biostatistics. Bayesian. Stan language.
Currently at Deparment of Bioinformatics, Second Faculty of Medicine, Charles University in Prague
2 Followers
117 Following
6 Posts
Joined November 01, 2022
Website:
GitHub:
Pronouns:
he/him
Replying to
@djnavarro@fosstodon.org 100%!!! As a shameless plug, a long time ago I wrote a short post about a similar topic, with verifying joins as an example: https://www.martinmodrak.cz/2018/09/17/tests-in-r-markdown/ Now that dplyr joins support those checks internally via the unmatched, multiple and relationship arguments there's even less reason to not doing those checks... People, check you joins!
Replying to
@cameron Yes, that looks OK. My vision woulde be to introduce a light community-driven management of the server and some way for people to chip in on the running costs...
Replying to
@EJWagenmakers@mastodon.social So unless you want to test the sampling algorithm itself, you are IME better off implementing the generator separately in your host language. It is also useful to avoid any tricks/shortcuts/optimizations you did for the probabilistic program and keep the generator simple. The more the implementations differ, the less likely are they to share the same bug. Does that make sense? 2/2
Replying to
@EJWagenmakers@mastodon.social @avehtari@bayes.club See https://hyunjimoon.github.io/SBC/ for a ready-made R implementation.
What you suggest could generate data for you in JAGS (in Stan, a bit more work is needed). You then need to fit your model to each of the posterior samples. However, using the same probabilistic program to draw from prior as you do for inferences is IMHO usually undesirable as any bug in the model will (usually) affect the prior and posterior the same way and you may fail to discover such a bug. 1/