There’s the additional constraint that for this to be reasonably efficient implemented as nested reverse mode autodiffs there should only be one output.
We can make lots of language constructs now that would leave us in a situation where people might accidentally write models that are inefficient to autodiff.
Parallelizing reverse mode solves this issue.
That’s what we do right now.
The other benefit from the reduce sum is that we autodiff in smaller chunks the grand function…that keeps the cpu caches hot. At least this is my understanding.
Not a lot is set in stone to be honest. The only thing I want to avoid is having to create Stan functions on the fly, which are mapped or reduced with a lot of arguments coming from different model components, for example ordinary regression coefficients, multilevel structure, splines, gps, etc.
The reason is that this will break the internal structure of brms’ Stan code generation requiring a single place to know much more / use much more information than what is currently required. If we use map on individual components, such as only to multilevel terms as in yours and Ben’s example, we should be fine in any case.
The problem with a map is that a huge Jacobian can be left in memory. The trick for an efficient map is to limit yourself in the number of shared arguments being used - but that’s not always easy.
Another avenue could be to allow users to switch off some code blocks generated from brms so that these can be replaced by the user with dedicated code. This would be a feature for those who want best performance and are willing to go with a semi-automated brms modeling approach. For that to work it would be great to have a bit more control where in the model block the stan code gets inserted. After variable declaration (right now the case), after setup of the parameter loops, after the prior or in place of the likelhood? Right now this is set in stone as I understood.
Before we go this route (give the user the option to move code to differnt blocks/replace them), we should determine of how general use this would be. I understand it is useful for you but we are actually quite far in the territory where I would usually recommend just going with Stan itself.
So the question is, what advantages does brms bring to the table (for example in terms of post-processing) for model requiring so much manual intervention in the Stan code?
Brms brings a ton of features for easy specification of priors and multilevel modeling structure. In addition there is all that post processing. I see brms as a package which I wish to extend so that users I work with can use a tailored brms setup for our problems…but all of this needs great care, of course.
I see and that makes sense. I think I the difficulty will indeed be to maintain all the post-processing options in the face of changes to the stan code.