Most stable Stan interface(s)

Interfaces
1

Over the years I have had a lot of anguish using RStan, due to its tendency to destabilize R and the frequent problems that crop up whenever Apple releases a new macOS. So I’m looking at moving to a different interface. Which ones are the most stable, reliable, and trouble-free? I’m guessing CmdStan is pretty reliable. What about CmdStanR? Is that ready for prime-time, or is it still experimental? How does PyStan compare to CmdStan and RStan?

1 Like
2

CmdStan is a minimal interface to the Stan services layer

  • model compilation is done directly using GnuMake (or Windows equivalent mingw32-make.exe)
  • running the executable provides one chain’s worth of inferences; outputs are in csv format

CmdStanR and CmdStanPy are lightweight wrappers around CmdStan which provide objects corresponding to the Stan model and the results of doing inference on the model given, either by running the NUTS-HMC sampler, any of the MLE optimization algorithms, or variational inference. They take care of model compilation and re-compilation, running multiple chains, managing the CmdStan output files, and they provide methods to extract the posterior estimates as in-memory objects appropriate for downstream inference.

Because CmdStanR and CmdStanPy wrap CmdStan, they can run any recent version on Stan, including the current release (v2.22.1) and will be able to run the next release (v2.23.0) because there are no changes to the CmdStan command line arguments in this release. Both PyStan and RStan lag the current Stan release by several versions.

You can use CmdStanR and CmdStanPy to fit models, and they will require only slightly more memory than CmdStan itself would, however when you extract the posterior sample as an in-memory object, this may require a lot of memory, depending on the number of parameters and quantities of interest and total number of draws.

CmdStanPy and CmdStanR are BSD licensed, while PyStan and RStan are GPL licensed, if that’s a concern.

are CmdStanR and CmdStanPy ready for prime time? they’ve both implemented the core feature functionality - there are still some nice-to-have issues/features on both interfaces. they need more beta-testing.

w/r/t Catalina and easy install, CmdStanR has a hiccup when installing CmdStan - you have to do a little dance to convince Catalina to trust the new stanc compiler. we’re working on solving that problem - it should be solvable because CmdStanPy doesn’t have this problem.

4 Likes
3

how ironic - Catalina is putting the stanc binary into quarantine

> xattr .cmdstanr/cmdstan/bin/*stanc
.cmdstanr/cmdstan/bin/linux-stanc: com.apple.macl
.cmdstanr/cmdstan/bin/linux-stanc: com.apple.metadata:kMDItemWhereFroms
.cmdstanr/cmdstan/bin/linux-stanc: com.apple.quarantine
.cmdstanr/cmdstan/bin/mac-stanc: com.apple.macl
.cmdstanr/cmdstan/bin/mac-stanc: com.apple.metadata:kMDItemWhereFroms
.cmdstanr/cmdstan/bin/mac-stanc: com.apple.quarantine
.cmdstanr/cmdstan/bin/stanc: com.apple.macl
.cmdstanr/cmdstan/bin/stanc: com.apple.metadata:kMDItemWhereFroms
.cmdstanr/cmdstan/bin/stanc: com.apple.quarantine

sorry apple - I’m staying home. bin/stanc just wants to be free.

4 Likes