Hi @seantalts, I read your “A Path Forward for Stan” document, and reading the section about FFIs, I was wondering whether you were aware of more concrete plans for expanding the usability of FFIs that were being put into place since your departure as Stan’s Technical Working Group Director (I’m not sure who your successor as the Interim Working Director is, if she or he exists at the moment). Tagging @ChrisRackauckas in this, as he’s interested in finding some way of porting his DifferentialEquations.jl in Stan in the future, which would also be related to the benchmarking discussions that he has had with @stevebronder.
Thanks for the ping. Yes I would be interested in setting up DifferentialEquations.jl as something that could be called from Stan. It would be helpful for figuring out what is allowing a given benchmark to be robust in Turing.jl: whether it’s a property of the ODE integrator or whether it’s solely due to the sampler. Right now we have to compare Turing.jl + DifferentialEquations.jl vs Stan (with internal ODE solver). Another interesting option would be to be able to call the sampler directly from other languages, similar to DynamicHMC.jl or AdvancedHMC.jl, without having to go through the Stan language. This would make it more accessible as a library component that could integrate with other PPLs and be interesting for PPL research.
1 Like
It’s not clear there will be such a person.
I don’t think there’s been any work on a foreign function interface.
Is there a writeup of something that’s robust in Turing.jl that isn’t in Stan? Are you using the stiff solver in Stan?
It was tracked down to be Errors thrown from ODE solvers are runtime errors. They should probably be domain_errors · Issue #1887 · stan-dev/math · GitHub . Using the stiff solver doesn’t make sense here since it was just on Lotka-Volterra.
can you elaborate a bit more on how you would envision using such a feature. Would this be an external library linked at compile time? Or would this be written in a user-supplied C++ file? Or something else.
I think something like this was already suggested awhile back https://github.com/stan-dev/cmdstan/issues/630
I think this would be something worth considering, if we can make it work in a way that does not put the bulk burden on the Stan team to maintain. So basically Stan provides the interface and C++ nuts and bolts while the rest is provided by whoever wants to supply their FFI.
For header only libraries this might be already doable with properly set makefile flags.
2 Likes
This user post from a Hacker News thread is an overview of one approach for being able to execute at least some of the solvers from DifferentialEquations.jl in Stan, which may be along the lines of what Chris is looking to do: https://news.ycombinator.com/item?id=23140058.
BTW, @ChrisRackauckas, you mentioned needing to be able to evaluate the gradients in Stan – based on that HN post, I think there may be a way to do so?
2 Likes