design-docs
design-docs copied to clipboard
stan-dev
Rust interface for CmdStan
N.B. no direct interface with C++!
This is a proposal for a CmdStan interface for the Rust programming language, analogous to the CmdStanPy et al. interfaces. There is one distinction, which some may consider a defect (critical input actively solicited): a strongly-typed representation of the CmdStan syntax tree.
link to rendered proposal: https://github.com/andrewjradcliffe/design-docs/blob/cmdstan-rs/designs/0035-cmdstanrs.md
Edit: add link
Kind of adjacent to this proposal, for a compiled language would something like a foreign function interface scheme be more appropriate? Using something like ffistan the rust interface would not need to compile a separate binary
Yeah, wrapping ffistan in rust is on my to-do list after I finish fleshing out the julia/python/R... but I can also imagine situations where someone would prefer a cmdstan wrapper even if they had an in-memory approach available. The simplest such example is one where you need to store a large number of draws for a large number of parameters and the total size is too big to store in memory
@WardBrian Does ffistan not use Stan's writer class? Then folks could just use the writer to write to disk. If it only takes in a pointer to an array to write to I think you could still use something like mmap on linux to write to disk
FFI would be nice, but, from inspection of ffistan there is still a call to make in order to build the .so. The resultant calls are through through the C ABI, which avoids the rigmarole of using a separate binary, spawning a process, communication, etc.
The proposed argument tree abstraction would provide a convenient way to direct high-level calls, analogous to the sample, optimize and pathfinder methods (Python) / functions (Julia) I see for the clients.
I think there could definitely be code-reuse between something in Rust that shells out to cmdstan and something that does it through CFFI. From a UX standpoint you still have the same issue with having a lot of arguments and no good way of doing defaults/named arguments except through a builder-like pattern.