As seen in the discussion within https://discourse.mc-stan.org/t/draft-stan-roadmap/6179 and Some issues that may arise regarding transformations there is plenty of differing opinions (although I believe that they are mostly due to misunderstandings rather than any substantial conflicts) about the current state, immediate future, and far future of algorithms in Stan. As the algorithm lead (leader, tzar, cihuacoatl, or whatever the we end up calling it) I wanted to lay out my current vision of these circumstances.
Currently Stan exposes MCMC with dynamic Hamiltonian Monte Carlo, MCMC with static Hamiltonian Monte Carlo, penalized maximum likelihood, and ADVI.
The algorithms implemented by the optimization code are mature but the code itself needs significant refactoring and improved testing.
Similarly the ADVI code is a sloppy and needs significant refactoring and testing. Additionally the algorithm itself is fragile and prone to failure. Refactoring would certainly help to isolate the various heuristic subalgorithms within ADVI and facilitate a more principled study of the various choices that might lead to a more robust algorithm, as would inclusion of diagnostics as recently worked on by @yuling and @avehtari. Regardless there is a ton of work to be done here and given the fragility of the underlying algorithm I would certainly not oppose removing it from the interfaces until it can be significantly improved.
Given our general user base I believe that we have need to focus on algorithms and user experiences that are both robust (i.e. they work on a wide class of problems) and diagnostic (i.e. they inform when they’re failing). For example, we can’t just add importance sampling corrections to an inaccurate algorithm if the algorithm can’t reliably get close enough for the corrections to be viable. If every fit ends with khat warnings them people will ignore the warnings or give up on Stan! Note that the current state of ADVI would fall strictly outside of this focus.
In my opinion the only algorithms with the potential for inclusion within this focus are variants of INLA. That said, exactly how these methods might be exposed is uncertain. Because INLA works well on a particular set of models it might not be well-suited to use as a general algorithm but rather a default algorithm in a higher-level interface like
brms where the class of models can be limited. Another possibility is defining marginal probability density functions that use INLA algorithms internally to approximate a high-dimensional marginalization.
In any case, while there is a promising future for incorporating methods developed for INLA into Stan but there is still plenty of uncertainty into how exactly that might proceed and hence plenty of research to be done. The work being done by @charlesm93 and @Daniel_Simpson is particularly important.
I’m not including Riemannian Hamiltonian Monte Carlo here because of its dependency on higher-order autodiff, but even once we figure that out there are a few adaptation/diagnostic issues that linger. Similarly Adiabatic Monte Carlo has one missing algorithmic piece that obstructs its general implementation.
Basically, everything else. One of the things that has made some of the recent discussions confusing is that some people are talking about preliminary, general research while others are talking about more mature, targeted research.
In my opinion if an algorithm does not have thorough pseudocode then it cannot be considered for inclusion into Stan and hence belongs in the far future discussion. This includes GMO, EP, and other heuristics that have been proposed. This does not mean that these algorithms will never be a part of Stan or aren’t worth researching (I’m reserving my persona judgement here) – it just means that they are not mature enough to warrant the technical overhead of discussing how they might be included in Stan. Maintaining this separation (i.e. “I’m working on this algorithm” or “I’m experimenting with this new algorithm I read about” verses “My colleague came up with a new algorithm – when will it be in Stan?”) will make it much easier for everyone to understand and participate in these discussions.
Stan is first and foremost a tool for users. It also happens to provide a powerful toolkit for researching and developing algorithms, but that use case becomes problematic when it compromises the first priority. For example, exposing algorithms that haven’t adequately been tested is problematic, as is unilaterally promising ill-defined or underdeveloped algorithms to users.
Again I think most of us are on the same page but confused because of the haphazard language of which we are all guilty. In the future please try to frame algorithm discussions into the basic themes “I want to fix an existing algorithm (here are experiments)”, “I want to propose an explicit algorithm (here are experiments)”, or “I am researching a new algorithm if anyone wants to check it out (here are experiments)”. Okay, technically the parenthetical aren’t necessary but they’re always highly encouraged.