Actually, they were released before Christmas. We will have to push some fixes to CRAN in the next couple of days to fix things on Solaris, but otherwise they should be fine for StanCon.
The main change with StanHeaders (the R package that includes the Stan Math Library) is that a commit was made that fixed the massive slowdown due to using strings rather than pointers to character arrays for function names.
The main change to rstan is that it should work with a Mac that uses the upstream version of clang (which CRAN now uses) rather than Xcode’s clang. It is necessary that the upstream clang be installed in /usr/local/clang4/bin/clang++. After that, there should be no more “unknown exception” messages.
- The default prior on the auxiliary parameter in GLMs (e.g. sigma if the likelihood is Gaussian) is exponential rather than Cauchy. You can still specify
prior_aux = cauchy()explicitly, although as always you probably will not get exactly the same numerical results as in previous rstanarm versions.
- Aki’s new hierarchical shrinkage priors made it in ( https://twitter.com/avehtari/status/948670477240864768 ) and have new arguments (
slab_df = 4and
slab_scale = 2.5).
- Models estimated with
stan_gamm4may be a bit different now that
mgcv::jagamto parse the formula rather than
You can also use (some of) the families in the mgcv package with rstanarm model fitting functions. For example, the
mgcv::betar family allows you to fit models with a beta likelihood using group-specific and / or non-linear functions with
stan_gamm4 as long as you are not parameterizing the auxiliary parameter (whereas the existing
stan_betareg function allows you to parameterize the auxiliary parameter with covariates but does not permit group-specific or non-linear functions).
A bunch of new functions were added to rstanarm, such as
bayes_R2which calculates the posterior distribution of the ratio of the variance (over the observations) of conditional mean to the variance of the predictive distribution for GLMs (including those with group-specific terms that you can condition on or integrate over). Andy already blogged about it.
stan_nlmerthat uses the same likelihood as
nlmerin the lme4 package, which fits models with a Gaussian likelihood but with a non-linear transformation of the linear predictor that can depend on group-specific terms. Even if you hate Bayesianism, the posterior means of these models (conditional on the group-specific terms) may well be more reliable than MLEs (that integrate over the group-specific terms), but watch out for multimodality in the posterior distribution
stan_clogitthat uses the same likelihood as
clogitin the survival package, which fits “case-control” models where by the research design a fixed number of observations within a group will be successes, such as a competition with exactly one winner per contest. The
stan_clogitformula is a bit different than the
clogitone in that the former can have lme4-style group-specific terms.
Finally, Sam Brilleman contributed a ton of code related to his Ph.D. dissertation. The
stan_jm function is a lot like the
JM function in the JM package or the
JMbayes function in the JMbayes package in that it estimates a “joint” model for the survival time and the severity of the symptoms for people with terminal diseases. These two things are obviously not conditionally independent, and you can specify a variety of dependence forms for the association structure. Also, Sam contributed
stan_mvmer, which is sort of a generalization of what
stan_jm does but for lme4-style models that have multiple outcomes with correlated error terms.
We are using a different build process for rstanarm now, so new R packages that come with compiled Stan models should follow this pattern, which is enforced by the
rstan_package.skeleton function in the rstantools R package. It is probably a good idea for existing R packages that come with compiled Stan models to migrate over to the new pattern, although not necessarily ASAP. Under the old way of doing things, Stan programs were in the
exec/ folder and chunks of Stan code were in the
inst/chunks/ folder. Now, Stan programs are in the root of the
src/stan_files/ folder and chunks of Stan code can be in subfolders of
src/stan_files/ and included via the “native” method in
#include statement must be flush left and there can be no whitespace or comments after the file name).
src/Makevars.win files cause the Stan programs to be compiled separately and then combined into a shared object (whereas before we were gluing all the C++ files into a massive C++ file and compiling that). The upshot of this is that (packages like) rstanarm can now be compiled with much less RAM than before. Conversely, it takes much longer to build rstanarm from source unless you have previously specified the environmental variable
MAKEFLAGS = -j4 or something (which negates the RAM savings). If you are not using Windows, the best of both worlds can be achieved by using link-time optimization in your local ~/.R/Makevars file and we may try to accomplish that automatically in the next version of rstanarm.