Rstan 2.18.2 released; everyone should upgrade to it now

Less than four months after the release of Stan 2.18, the rstan package is ready for general use. Many of you were already using rstan 2.18.1, but that was never announced because it was challenging to get the C++ toolchain configuration right on Windows. It is now easier than ever to get rstan to work on Windows, but even if you do not use Windows, you should update to rstan 2.18.2 now.

We strongly recommend everyone use RStudio version 1.2.x when working with rstan, even though it is still in beta
because it has fantastic support for editing Stan programs, which is described at
So, if you do not have RStudio installed or have been using version 1.1.x, you should install the 1.2.x beta now.

We have revamped the “RStan Getting Started” wiki page

but in short

  • On Windows, everything should be fine as long as Rtools can be installed and it is no longer necessary to adjust the PATH environmental variable
  • On a Mac, everything should be fine if you previously used the toolchain installer and you have not yet upgraded the operating system to Mojave. Otherwise, if you have upgraded the operating system to Mojave, you may have to use the toolchain that comes with Xcode for a little while. This has caused trouble for several people, so open a new thread if that includes you.
  • On Linux, you should already have a C++ toolchain, but Stan now requires as much of the C++14 standard that is implemented by g++-4.9 or clang++-3.4. So, you may need to install and / or use a more up-to-date version of your C++ compiler. See here for more information.

The main changes in rstan relative to 2.17.x (aside from automatically finding the C++ toolchain on Windows) are

  • The effective sample size is now estimated without bounds that restrict the estimate to be between zero and the nominal number of post-warmup draws. Thus, you may get “super-efficient” estimated posterior means where the effective sample size exceeds the nominal number of post-warmup draws because the first-order autocorrelation is negative. Also, you may get negative effective sample size estimates, in which case the sampling was completely unreliable (@avehtari says that this is only likely when you only use one chain, in which case the problem is that you only used one chain)
  • Specifying refresh = 0 eliminates all intermediate output and progress reports
  • The compiler warnings won’t be printed to the screen by default; specify verbose = TRUE in the call to stan or sampling if you need to see them for some reason.
  • The unconstrain_pars method can now return an entire matrix of unconstrained parameters across all iterations and chains
  • There is a loo.stanfit() method that can be used if your Stan program has a log_lik element in its generated quantities that is a vector of contributions to the log-likelihood by each “observation”
  • There are a now a bunch of get_ functions to get HMC diagnostics programatically
  • The internals of expose_stan_functions work differently now, which should allow it to work for all possible user-defined Stan functions, but likely have introduced new bugs so let us know if it does not work in your situation

Is Rstan 2.18.2 significantly faster than 2.18.1 when calling “sampling” function for NUTS?

No (well, it might be on Windows if you set Sys.setenv(-march = 'native') as the startup message suggests or make that change in ~/.R/

Thank you.

Does it allow user-defined gradients?


Also, we could use translations of the “Getting Started with RStan” wiki page. See

That should have been Sys.setenv(LOCAL_CPPFLAGS = "-march = 'native'"). Anyway, if you do that on Windows and run into Stan segfaults, please let us know.