It means models which do not use functions that the Stan Math Library lacks higher-order autodiff support for. Generally these are the implicit functions like algebra_solver, ode_rk45, etc.
If the model is unsupported, C++ compilation should fail, so when in doubt it is reasonable to try it and see if it can compile
This looks cool, but Iām a little confused about the motivation of this versus cmdstan. What is the significance about having access to log_prob and gradient functions?
The C-level API is probably the part that is most interesting to me as it would make calling Stan from other languages easier, presumably. But the function signature looks like it takes a path to a json file? What if you have the json data in memory (then if I have some data I just need to serialize it to json to run it through this)? It would be nice to be able avoid unnecessary writes to files (admittedly, Iām pretty sure this is also an issue with cmdstan).
The idea is it is much easier to implement and compare new algorithms in a language like R or Python. This is certainly not a CmdStan replacement, but is instead targeting developers and tool builders
We could probably add into a version which accepts the json as a string as well, rather than a file. Some form of serialization will be necessary to allow communication between languages, but it isnāt necessary that it be a file
Ah ok, thanks for that explanation. Unfortunately, I donāt think I would probably make much use of it (so donāt go adding new overloads for my benefit). I was interested in the C API specifically wrt being able to easily call Stan from other languages that arenāt R/Python/Julia. While I can use CmdStan, my understanding is that I need to save the data to a file first.
BridgeStan 1.0 is now out! Please continue discussion in the new announcement thread BridgeStan 1.0.0 released
This is amazing, just found out about this by hearing you on the the learning Bayesian stats podcast. Just what I need to consider using Stan in our Workflows.