@Ven_Popov I’ve finally had a closer look at bmm and it looks amazing! Across these various packages that extend brms, it seems like their goals generally include one or more of:
- Adding a specialized custom family
- Providing a UI that translates between “familiar” notation as seen in the subject-matter literature and valid
brmsformulas - Providing developer tools to lubricate the above (
bmmonly) - Providing specialized post-processing functionality specific to model types.
I’m kind of blown away by how useful bmm looks to be for the first three bullets, and I wonder if you would have any interest in providing the developer tools portion of the package as a stand-alone framework that people can clone and use to build their own packages.
Unfortunately, in flocker we couldn’t come up with the sort of solution that could fit inside the bmm framework. There are at least two issues that prevent this, both arising from the complicated indexing problem that sits at the heart of our data spec. One issue is that we need to generate the custom families on-the-fly at runtime, because the Stan snippet for the family depends on the number of repeat visits in the dataset. The other issue is that we need to reimplement most of the brms post-processing functionality in order that it play nicely with our format, since predictions, log-likelihood calculations, etc depend on the dependency structure encoded by the indexing. Still, bmm is an inspiration for opportunities to streamline and modularize the flocker codebase.