I made a major fix to the algebraic solver that allows users to pass parameter-dependent initial guesses. There are pull-requests, and I just need to fix some cpplint errors (having issues running it on my machine, working on a fix).
It’d be great to get this new feature out there. What is the timeline for releasing Stan 2.18?
Similar boat w.r.t. getting the much-simplified expose_stan_functions into Stan (and that math p.r…)
Into rstan that is. The math p.r. would be fun to see go off in to the sunset but I don’t think anybody else cares about that one.
What’s the issue number for RStan? Any chance we could adapt it for PyStan?
This is what the rstan code for it, but exporter.hpp is Rcpp-specific so we’d need some more code there.
expose_stan_functions_hacks <- function(code) {
code <- paste("#include <exporter.h>\n#include <RcppEigen.h>", code, sep="\n")
# code <- sub("_header.hpp>\n", "_header.hpp>\n#include <stan/model/model_header.hpp>",
# code, fixed = TRUE)
code <- sub("// [[stan::function]]",
"// [[Rcpp::depends(rstan)]]\n// [[Rcpp::export]]", code, fixed = TRUE)
return(code)
}
expose_stan_functions <- function(file, ...) {
model_code <- get_model_strcode(file, NULL)
model_cppname <- legitimate_model_name(basename(file), obfuscate_name = TRUE)
r <- .Call("stanfuncs", model_code, model_cppname, allow_undefined = FALSE)
code <- expose_stan_functions_hacks(r$cppcode)
compiled <- Rcpp::sourceCpp(code = paste(code, collapse = "\n"), ...)
return(invisible(compiled$functions))
}
This is why I was trying ot keep an eye on the C++/Pystan interfacing discussion but I don’t have time a.t.m. to do it myself. The Rcpp extensions in exporter.hpp are really limited and it wouldn’t be hard to pull off something similar for Python.
Sounds good. Thanks.
I’ve created an issue in PyStan,
@bgoodri Is there anything you wanted in 2.18 that isn’t in develop? We’re talking about doing the release today.
Edit: Never mind, we’re going to cut a releast on Feb 15 so that we get more into 2.18 and it’s closer to RStan 2.18.
I can’t release rstan 2.18 for another month anyway, so that seems good. I am not a fan of calendar-based releases but it does seem like we should release as soon as the MPI stuff is ready.
I am quite biased here, but releasing once MPI is in does make sense… but I could use help to meet Feb 15.
I am a fan of numerical integration. I would like you to consider if you can make it in time for Stan 2.18 if possible.
the ODE integrators can be tweaked to do numerical integration for you. A dedicated numerical integrator will likely be more efficient, but you can work around the problem. There are a few posts on this already.
The ODE integrator trick often requires significant analytic work to tame the transformed integrands that arise when you try to accommodate integrals to infinity, where as the algorithm used in randommm’s PR can handle them without any such work. I second @MatsuuraKentaro’s call to finally get this in.
Anyone know what the holdup is on that one? The licensing is ironed out, but I don’t know what’s holding it up. I’ll ping the PR again.
OK. Merged. It was my fault! I was supposed to be reviewing it, but lost it in the pileup of other math issues. I’ll go and write the language interface now.
Do you guys have a target release date by chance? I’m keen to try out Charles’s changes to the algebraic solver!
wrt the GPU stuff I could see us being finished in May. If everyone wants an earlier release date it may be good to push the GPU functions into the next release
What is left to be done? The Stan release after next may well not happen until right before StanCon.
At one point we had said we were going to wait for MPI, but I would estimate that that will be at least a few weeks for the code review.
This week we are finishing up the OpenCL context creation piece. Then we have
So overall at least a month or two. Probably 1.5 months. Though maybe we can go a bit faster