It compiles (I haven’t tried to run it) if you also specify a tolerance after x_i, which according to the documentation should be an optional argument. Did anything change regarding that?
Yeah it should be optional. At the Math C++ level it is so I’m guessing it’s at the Stan level. @mitzimorris do you know how to change the Stan language stuff for this? As I remember there was something weird about getting this into the language cause it has the function argument n’ such.
halair ~/tmp $ curl -L -O https://github.com/stan-dev/stanc3/releases/download/nightly/mac-stanc
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 600 0 600 0 0 3074 0 --:--:-- --:--:-- --:--:-- 3076
100 9.7M 100 9.7M 0 0 5872k 0 0:00:01 0:00:01 --:--:-- 8654k
halair ~/tmp $ chmod +x mac-stanc
halair ~/tmp $ pbpaste > integrate1d.stan
halair ~/tmp $ ./mac-stanc integrate1d.stan
Semantic error in 'integrate1d.stan', line 38, column 16 to line 41, column 53:
-------------------------------------------------
36: left_limit ~ normal(0, 1);
37: target += normal_lpdf(y | mu, sigma);
38: target += log(integrate_1d(normal_density,
^
39: left_limit,
40: positive_infinity(),
-------------------------------------------------
A returning function was expected but an undeclared identifier 'integrate_1d' was supplied.
Looks like we don’t have integrate_1d yet - the feature was merged in March, after we stopped work on the old compiler, but no issue was made on the stanc3 repo to track it. I’ll add one now: https://github.com/stan-dev/stanc3/issues/301
there were a bunch of reasons we moved the docs out of the Stan repo - one of them was to cut down on CI overhead, another was because of the burden of installing the docs toolchain - pandoc, latex or equiv, etc.
another was because it gives the online docs a nice URL via GitHub pages - https://mc-stan.org/docs/2_20/stan-users-guide/…
although https://mc-stan.org/stan/2_20/stan-users-guide/…
looks OK as well, so no big.
if you think they need to be moved back, it can be done.
As a contributor to the docs repo, I find that having a separate repository makes things much easier to deal with. But I guess that if consensus is to merge with the rest, I’ll find my way through it.
Cool, that’s good to hear. I just remember some conversations around figuring out how to sync the doc versions with the code and line them up properly, but maybe @mitzimorris came up with a versioning scheme inside the docs repo instead? I’m seeing these 2_19 and 2_20 URLs on Google (so happy the manual is google-able now!) so that’s probably it. I guess this just decouples the PR process for Stan code and docs so they’re done separately. Sounds good to me, never mind :)