this issue should be used to note all broken or missing cross-references for this docset.

Summary:

I don't think referring (arguably incorrectly) to Google's Map-Reduce framework as the section title in our manual is helpful. I might suggest other names for the section and a lack of references to Map-Reduce since 1) we only have map_rect right now (no reduce) 2) we don't share almost anything with the Google implementation of these ideas.

Current Version:

v2.18.0

Summary:

In https://mc-stan.org/docs/2_18/stan-users-guide/truncated-random-number-generation.html
all the examples with normal_rng should have inv_Phi instead of Phi. See also https://discourse.mc-stan.org/t/rng-for-truncated-distributions/3122/10.

(I can also fix it myself, but should I do a pull request to master?)

Current Version:

v2.18.0

Summary:

The PRNG functions are available in the transformed data blocks as well as in generated quantities block - this is correctly documented in the users guide and reference manual but the functions reference needs to be updated.

Description:

Stan issue stan-dev/stan#1644 changed the Stan language to allow calls to RNG functions in the transformed data block. The documentation in the functions reference manual need to be changed from statements like:

may only be used in generated quantities block

to

may only be used in transformed data and generated quantities block

Additional Information:

cross-reference to section in user's guide?

Current Version:

v2.18.0

Summary:

This is the place to record typos and brainos or suggestions for the manual. Most of the changes for 2.18 have already been merged, but we might make another round of updates before the 2.18 release. Otherwise, these will go in the release after that.

Current Version:

v2.17.1

Summary:

Basic rendering bug in 12.1.1-3

Description:

This does not have pretty math in my browser (Firefox ESR):
https://mc-stan.org/docs/2_18/functions-reference/binomial-distribution.html

Current Version:

v2.18.0

Summary:

Descriptions about how to use new covariance functions.

Description:

Additions IBNLT

1. combining kernels,
2. ARD: de-mystify, how to use new implementation
3. new functions and their properties
4. more examples that are currently in there (something with periodic/matern/dot product).
5. Computational limits of GPs in Stan (wrt to Stan's autodiff, etc).

More generally, try to forecast errors that new users of GPs will have, so we can document properly. Disambiguation.

I'll update as I think of stuff, this is a place holder.

Current Version:

v2.19.0

Reorganize top-level structure:The top-level organization here is broken:

LICENSE and LICENSE2

The same license (BSD-3 code, CC-BY ND text) applies to all of the repos here. Remove LICENSE2 file and include contents in LICENSE. Included there, not that it applies to all of the content in this repo.

README.md vs. README2.md

There should only be one top-level README.md that provides an overview of everything in the repo. If you need README files for subdirectories, then those should go at the top of the subdirectory structure. The README should explain that the docs/ directory is for built documents (if I guessed what it is properly) and the

docs directory structure

Why is there a lone docs/img directory with just the logo? Is this meant to be images shared across the various builds?

What is docs/libs? This is where a docs/README might be useful---to explain what everything is and where it's organized. The goal is to have doc that will explain to someone working on this where things go.

Versioning in /docs

I don't like the lack of parallelism among

• docs/bayes-stats-stan
• docs/2_18/functions-reference
• docs/2_18/reference-manual

Unify this so that both are docs/<title>/<version> or both are docs/<version>/title. We will release a version of the bayes-stats-stan book with each numbered release.

This is all assuming we only put out docs for major releases. I'm OK with that, but it should be documented in the top-level README for the whole repo how the releases work and how everything's organized.

Organization of docs/src/

There's no R used in index.Rmd, so this should be replaced with index.md (unless it's possible to provide a more informative name, this needs to be documented in the readme) and the _bookdown.yml and _output.yml should be eliminated (and any scripts updated to take that into account).

The other solution, which I like even better, is to move the directory into the actual web site directory and only serve the actual manuals from this site. It may not work as there may be an assumption that there's an index here. If so, you'll have to use your judgement and doc around possible confusions.

We will probably wind up in the end having different styles for the three documents. For now, if the top-level docs/src/stan-manual.css is being used by all three of the documents then it's OK to leave it at the top. But then I see the stan-manuals.sty repeated in the subdirectories. Whatever happens, the .sty for LaTeX and .css for HTML should go in the same place if they're both there.

docs/src/bayes-stats-stan/ organization

There shouldn't be three parallel directories for mining-disasters, programs, and stan---this needs to get organized coherently. There needs to be a coherent and consistent way (particularly in terms of naming) for organizing:

• stan models
• the data that goes with them
• the R code needed to run them

That means either organizing by programs/<name>/{ .stan, .data.R, .R} or by programs/{stan, data, scripts}/<name>. Whatever it is, it should be consistent so users don't have to crawl all over the directory structure to piece things together.

The R code to run this stuff is a holdover from before things were in markdown. This R needs to be integrated into the markdown the R code directory here eliminated.

_build.sh vs. _build_book.sh

Create a single top-level build.sh (don't use the underscore). That should build all of the doc in the repo. It can call other build scripts that are pushed down to the local repos if you would like, or the top-level can just call everything. But there should not be two build scripts at the very top. An alternative (choose one, don't use both) would be to have a makefile---that's more portable to Windows.

Update manual so there is:

• syntax highlighting for Stan code
• code split out into separate files
• test code segments for syntactic correctness against parser

From @bnicenboim on December 2, 2018 12:21

Line 8 of the unmapped implementation in the user guide's page 241 has this line:
vector[2] beta[K];

And this produces the following error:

SYNTAX ERROR, MESSAGE(S) FROM PARSER:

No matches for: 

  real[] .* vector

Available argument signatures for operator.*:

  vector .* vector
  row vector .* row vector
  matrix .* matrix

No matches for: 

  real[] + ill formed

Available argument signatures for operator+:

  int + int
  real + real
  vector + vector
  row vector + row vector
  matrix + matrix
  vector + real
  row vector + real
  matrix + real
  real + vector
  real + row vector
  real + matrix
  +int
  +real
  +vector
  +row vector
  +matrix

Expression is ill formed
  error in 'model1a7a481d4cfe_no_map_rect' at line 18, column 53
  -------------------------------------------------
    16:   for (i in 1:2)
    17:     beta[ , i] ~ normal(mu[i], sigma[i]);
    18:   y ~ bernoulli_logit(beta[kk, 1] + beta[kk, 2] .* x);
                                                            ^
    19: }
  -------------------------------------------------

I'm pretty sure that this line should be matrix[K, 2] beta;
which fixes the error.

Current Version:

v2.18.0

Copied from original issue: stan-dev/stan#2707

Summary:

The manual says that .* and ./ bind more tightly than * and /. However, based on my experiments, Stan currently implements .* and ./ as having the same precedence as * and /.

Description:

We need to update the manual to list the precedence of ./ and .* to be the same as * and / (so less tight binding than \ ).

Additional Information:

Provide any additional information here.

Current Version:

v2.18.0

Summary:

Add doc for this PR: stan-dev/stan#2758

Current Version:

v2.18.0

review regression chapter - recommendation for half Cauchy should be half Normal or whatever latest "fatwah" (Andrew's words).

Summary:

1D Integrator: No documentation

Description:

It is my understanding that the 1D integrator is now part of version 2.18/2.19. However, the documentation for use is not in the manual (at least for the 2.19 version).

Additional Information:

Current Version:

v2.18.0

Summary:

Currently, lp__ still appears in the reference manual as being deprecated. However, it has already been removed from the language.

Description:

lp__ should be removed from the deprecated features list in the reference manual.

Additional Information:

Current Version:

v2.18.0

Summary:

New log_mix functions allow for use with vectors and arrays (as opposed to the current version which is a ternary scalar function), need to update the manual to reflect this (both in terms of function signatures and examples).

Description:

I'm writing up changes to the manual to add the new signatures for log_mix (as in stan-dev/stan#2532).

• The function is currently listed under 'Composed Functions' with the signature (real theta, real lp1, real lp2) (page 455), should I add the new signatures here or should I make a new entry in 'Matrix Operations'?
• Given the amount of new valid signatures (15), should I add all of them or only part?
• There are several examples in the manual using log_sum_exp for mixtures with more than two components, should I rewrite these to use log_mix or leave that for a separate pull?

Current Version:

v2.17.1

Summary:

The doc should indicate the precision of the ASCII output.

Description:

Longer term, we'll want to control the precision, but now it's fixed and we should mention what it is.

Current Version:

v2.17.1

Summary:

Both

https://mc-stan.org/docs/2_18/reference-manual/effective-sample-size-section.html

and

https://mc-stan.org/docs/2_19/reference-manual/effective-sample-size-section.html

have an incorrect mathematical manipulation with respect to rho_t.

Description:

Taken from stan-dev/stan#2762,

"""
I am confident the implementation in Stan is correct, this issue is only about the documentation.

The issue is with the claim that the autocorrelation integral term (t-mean)(s-mean) simplifies to ts, but it actually simplifies to ts - mean^2, and the derivation in Section 15.4.1 ommits the squared mean.

The correct simplified autocorrelation equation should read
"""

\rho_t = \frac{1}{\sigma^2} \int_{\Theta} \theta^{(n)} \theta^{(n+t)} p(\theta) d\theta - \frac{\mu^2}{\sigma^2}.

Current Version:

v2.19.0

Use (and perhaps upgrade) the java2tex system for the manuals. That will allow naming blocks of models with comments and then pulling the relevant text out into a LaTeX-friendly file to include.

• try the java2tex system on our text
  • update if necessary
• create directory structure (or submodule structure?) to find models
• replace all the code examples in the manual with extractions from compiling models

Summary:

Please provide a short couple sentence summary.

Description:

Describe the issue as clearly as possible.

Additional Information:

Provide any additional information here.

Current Version:

v2.18.0

Summary:

There is a small typo in section 15.2 Normal-Id Generalised Linear Model (Linear Regression) of the Stan function reference. The (wrong) function name does not exist as a function in Stan/math.

Description:

In section "15.2.3 Stan Functions" the Stan function for the Gausssian regression model is called 'normal_id_glm_lpmf', but it should be 'normal_id_glm_lpdf'.

Current Version:

v2.18.0

Summary:

There are some of GP models in the Example Models/Gaussian Process Section of the Reference Manual that are invalid, and there also need be updated for some of the new kernels.

Description:

I will make a list of things I've noticed, and this is in no way designed to be comprehensive, and I will update this post as I go:

1. The joint distribution for unobserved y is contained in the total covariance matrix. On Page 259/260, we have something like the following:

transformed data {
  real delta = 1e-9;
  int<lower=1> N = N1 + N2;
  real x[N];
  for (n1 in 1:N1) x[n1] = x1[n1];
  for (n2 in 1:N2) x[N1 + n2] = x2[n2];
}

This does not make sense. We simply need two x vectors: x and x_pred, where x_pred are the out of sample predictions. If we take

generated quantities {
  vector[N2] y2;
  for (n2 in 1:N2)
    y2[n2] = normal_rng(f[N1 + n2], sigma);
}

then we generate predictions for indeces greater than N1 that are essentially just normal random variates, and we are incorporating nothing in we've approximated in the model. Another note, since we have a gaussian likelihood, we do not need the latent f and instead can use y directly. We only need latent f in generated quanties when the likelihood is non-gaussian.

Instead, we use matrix algebra (i.e. using the posterior predictive mean function and posterior predictive variance, and then the data and generated quantities blocks can look the same for all models and look something like this (for ARD/seperate length scale):

data {
  int<lower=1> N;
  int<lower=1> D;
  vector[D] x[N];
  int<lower=0,upper=1> y[N];

  int<lower=1> N_pred;
  vector[D] x_pred[N_pred];
}
parameters {
  real<lower=0> magnitude;
  real<lower=0> length_scale[D];
  vector[N] eta;
}

assuming we generate the predictive posterior correctly, and there is an example below.

2. I'm also keen on generating out of sample and in sample predictions in my generated quantities block. For binary classifier, assuming we've generated the latent f* properly (using f*, following GPML notation), this is as follows:

generated quantities {
  vector[N_pred] f_pred = gp_pred_rng(x_pred, f, x, magnitude, length_scale);
  int y_pred[N_pred];
  int y_pred_in[N];
  
  for (n in 1:N) y_pred_in[n] = bernoulli_logit_rng(f[n]); // in sample prediction
  for (n in 1:N_pred) y_pred[n] = bernoulli_logit_rng(f_pred[n]); // out of sample predictions
}

3. We also need note that the posterior predictive can based on likelihood or noise model we're assuming, and also on the covariance function. For example, in the binary classifier, logit example, we only need the mean function (Also note, I'm using the mean function without noisy predictions):

functions {
  vector gp_pred_rng(vector[] x_pred,
                     vector y1, vector[] x,
                     real magnitude, real[] length_scale) {
                     ) {
    int N = rows(y1);
    int N_pred = size(x_pred);
    vector[N_pred] f2;
    {
      matrix[N, N] K = gp_exp_quad_cov(x, magnitude, length_scale);
      matrix[N, N] L_K = cholesky_decompose(K);
      vector[N] L_K_div_y1 = mdivide_left_tri_low(L_K, y1);
      vector[N] K_div_y1 = mdivide_right_tri_low(L_K_div_y1', L_K)';
      matrix[N, N_pred] k_x_x_pred = gp_exp_quad_cov(x, x_pred, magnitude, length_scale);
      f2 = (k_x_x_pred' * K_div_y1);
    }
    return f2;
  }
}

This wasn't as organized as I'd hoped but it hits on some points.

Reproducible Steps:

If you copy and paste some of the notation in the Stan manual and plot the in sample predictive distribution, you will see what I'm talking about.

Current Version:

v2.18.0

Moved from @lamhm's stan-dev/stan issue stan-dev/stan#2771.

Description:

On the 4rd lines of page 125 in the PDF document (BNF Grammars section), the text should be:
assignment_op ::= '<-' | '=' | '+=' | '-=' | '*=' | '/=' | '.*=' | './='

instead of:
assignment_op ::= '<-' | '=' | '+=' | '-=' | '*=' | '/=' | '.*=' | '/*='
(notice the last operator).

Current Version:

v2.19.1

Summary:

markdown code includes png (speeds up build), but we don't
have the R code checked in which generates these images.

Description:

following files include pngs - need code which creates these

./stan-users-guide/simple-examples.Rmd
14:    dev = "png",
209:![Golf diagram](img/golfpicture.png)
./stan-users-guide/problematic-posteriors.Rmd
250:![Two intercepts with improper prior](img/non-identified.png)
254:![Two intercepts with proper prior](img/non-identified-plus-prior.png)
258:![Single intercepts with improper prior](img/one-param-identified.png)
./stan-users-guide/efficiency-tuning.Rmd
268:![Neal's funnel density](img/funnel.png)
297:![](img/funnel-fit.png)

Additional Information:

Provide any additional information here.

Current Version:

v2.18.0

Summary:

The hyperlink to the section Priors for Gaussian Process Parameters in the users guide for 2.18 is not working.

Description:

Search for "Priors for Gaussian Process Parameters {#priors-gp.section}" and you will see the problem. I think this is only a problem in the html version.

Additional Information:

Provide any additional information here.

Current Version:

v2.18.0

Summary:

The Stan Functions Reference index should index all functions for a distribution - e.g.

bernoulli;~;real;92
bernoulli_cdf;(ints y, reals theta);real;92
bernoulli_lccdf;(ints y | reals theta);real;92
bernoulli_lcdf;(ints y | reals theta);real;92

currently entries for _cdf et al. are missing.

Description:

Conversion from latex to Rmd garbled functions reference index entries for latex manual - index entry in HTML comment is correct, latex entry is missing suffix:

<!-- real; bernoulli_lpmf; (ints y | reals theta); -->
\index{{\tt \bfseries bernoulli}!{\tt (ints y | reals theta): real}|hyperpage}

should be:

<!-- real; bernoulli_lpmf; (ints y | reals theta); -->
\index{{\tt \bfseries bernoulli\_lpmf}!{\tt (ints y | reals theta): real}|hyperpage}

Current Version:

v2.19.0

Summary:

The table referenced in section 9.4 ("Coding Ragged Arrays") is present in the PDF output but not the HTML output.

Description:

The table present in the PDF user guide on page 129 with columns 'n', 'w[n]', and 'doc[n]' is missing from the HTML output.

A second, possibly related typography bug is that the PDF table typesets the characters 'n' where \texttt{n} and similar are likely better (so the typography would match the following text).

Additional Information:

The table missing is:

Current Version:

v2.19

Summary:

Conversion from latex to Rmd failed to register signatures some functions. also missing entries for sampling statements for distributions.

Description:

Every function signature should have an accompanying HTML comment, e.g.:

<!-- real; min; (real[] x); -->
<!-- int; min; (int[] x); -->

Comparison to info scraped from latex index indicates about 50 missing signatures - need to check out 2.18.1 release, run task make manual, and examine file doc/stan-functions-2.18.1.txt

Additional Information:

Current Version:

v2.19.0

Summary:

Return codes for the executable for compiled Stan programs are not defined. Define them and add them to the CmdStan documentation.

Description

Return code 0 should indicate that everything returned normally and that all expected output exists. It does not need to indicate that the resulting sample is reliable.

Current Version:

v2.19.1

Summary:

document the addition of adam-moulton ODE solver

Description:

https://discourse.mc-stan.org/t/ode-roadmap-different-solvers/8766/4

Additional Information:

Provide any additional information here.

Current Version:

v2.18.0

This is the issue for things that would be nice to get into the manual in the future. Rather than closing this issue, we'll just tick things off as part of the regular round of "next manual" issues.

Summary:

Equation for sampling distribution of h_t has a typo.

Description:

Both the RHS and LHS of recurrence equation

use h__t. RHS should be using h__t-1

Current Version:

v2.18.0

We aren't testing code that goes into the manual thoroughly and automatically enough. We need a framework where code citations in the manual are automatically extracted from running code and then pasted into the manual.

Summary:

This is the place to record typos and brainos or suggestions for the manual.

Current Version:

v2.18.1

Summary:

Accessing https://mc-stan.org/docs gives me a 404 (though now I know I can go to https://mc-stan.org/docs/2_18/reference-manual/index.html

Current Version:

v2.18.0

Looking at the code and examples, I think that the following holds:

1. for array (matrix, vector, etc) variables, column names varname[i,j,k] appear as varname.i.j.k in the CSV header line,
2. for the same varname, the range of colums is contiguous, ie one cannot have a.1, b, a.2 columns in the posterior dump,
3. within the contiguous block, array elements are in column major order
4. for arrays of vectors/matrices, the same arrangement applies as in the data dump

Are the above true?
Could they be briefly documented in an Appendix of the CmdStan manual?
This would be helpful as I am writing a tool that parses these files.

Summary:

As mentioned in the Discourse thread here we should add a section on determinism in scientific computing (numerical reproducibility).

Description:

Below is my draft for this section. Once the text is approved I can make a PR.

Numerical reproducibility is the problem of getting the exact same numerical result in all runs of the same algorithm. In the context of Stan this would mean that a model with the same seed and input data produces the exact same samples in the same order every time we run it.

There are two main issues that prevent numerical reproducibility:

a) Differences in implementation of floating point arithmetic

Most current processing units, CPU and GPU, follow the same variant of the IEEE754 standard. However, the standard allows for different implementations of rounding that can lead to numerical differences. This makes it more difficult to achieve numerical reproducibility across different systems.

b) Non-determinism of the order of arithmetic operations

A sequential algorithm with the same random seed will always perform all arithmetic operations in the exact same order. Rounding will always occur at the exact same points. However, if the algorithm includes parallel reductions, the order of operations is no longer deterministic. Rounding may occur at different points and lead to numerical differences. This goes for simple cases of 4 threads performing a reduce_sum on a vector as well as GPU functions running on thousands of threads.

Additional Information:

/

Current Version:

v2.18.0

Summary:

Please provide a short couple sentence summary.

Description:

Describe the issue as clearly as possible.

Additional Information:

Provide any additional information here.

Current Version:

v2.18.0

Summary:

HTML link incorrect

Description:

link in sparse-matrices.html to csr.html should be CSR.html

Additional Information:

Problem is probably due to developing on a case preserving filesystem (mac, windows)
but deploying on a case sensitive filesystem (linux)

Current Version:

v2.18.0

Summary:

The GLM functions
bernoulli_logit_glm
neg_binomial_2_log_glm
normal_id_glm
poisson_log_glm
do not appear in the functions reference or reference manual anymore, though they definitely used to be in there.

Description:

I wrote manual entries for these functions when I originally submitted my PRs, but they seem to have disappeared in the version of the doc for 2.18 on https://mc-stan.org/users/documentation/ .

Additional Information:

Provide any additional information here.

Current Version:

v2.18.0

Summary:

Sec 2.1 on Autoregressive models contains a minor error in the description of AR(1) models.

Description:

I had made a comment on the previous manual about an alternative parameterization for an AR(1) model with a non-zero mean (level). The current version of the manual has acknowledged that (thanks!), but there is a typo/error in footnote 7.

It currently reads,

The intercept in this model is $\alpha / (1 - \beta)$. An alternative parameterization in terms of an intercept $\gamma$ suggested Mark Scheuerell on GitHub is $y_n \sim \text{normal}(\alpha + \gamma (x_{n-1} - \alpha), \sigma)$.

but it should read,

The intercept in this model is $\alpha / (1 - \beta)$. An alternative parameterization in terms of an intercept $\gamma$ suggested Mark Scheuerell on GitHub is $y_n \sim \text{normal}(\gamma + \beta (x_{n-1} - \gamma), \sigma)$

Current Version:

v2.18.0

Summary:

"id: " tags are printed in PDF of User Guide v2.19, ODE section

Description:

In the Users manual section 13 (ODEs), the equation blocks are followed by the printed tags, e.g. "id:ode-sho.equation" (p168), "id:ode.linODEs" (p170), etc.

Additional Information:

Current Version:

v2.19.0

Summary:

This is the place to record typos and brainos or suggestions for the Stan manuals: User's Guide, Reference Manual, Functions Reference. Please report broken links, incorrect code or math as well as questions and corrections to discussion and modeling advice.

Current Version:

v2.19.0

Summary:

qr_R doc text has an error

Description:

Currently it reads:

matrix qr_R(matrix A)
The upper trapezoidal matrix in the fat QR decomposition of A, 
which implies that the resulting matrix will be square with the same number of rows as A

I think that the last part should say "...the resulting matrix will be rectangular with the same dimensions as A"

Additional Information:

If I run the program:

data {
  int n;
  int p;
  matrix[n,p] ss_v1;
}
model {
}
generated quantities {
  matrix[n,p] foo;
  {
    foo = qr_R(ss_v1);
  }
}

with Data:

  val matrix = Seq[Seq[Double]](Seq(17, 9, 13), Seq(9, 22, 31), Seq(13, 31, 50), Seq(1, 4, 9), Seq(8, 20, 36), Seq(21, 48, 81))

I get back the rectangular matrix:

Vector(
  Vector(32.3265, 59.5797, 97.3815), 
  Vector(-0.0, 26.3868, 45.1378), 
  Vector(-0.0, -0.0, 6.88628), 
  Vector(0.0, 0.0, 0.0), 
  Vector(0.0, 0.0, 0.0), 
  Vector(0.0, 0.0, 0.0)
)

Which seems to confirm the change. If I change the dimensions of the generated quantity to be N x N or P x P, it does not compile in CmdStan.

Current Version:

v2.18.0

Hi!

I discovered the "bayes-stats-stan" documentation and started reading the Introduction on mc-stan.org (This one or the pdf-version on github).

I simply wanted to reproduce the first Hello World but stumbled upon an R-function used in the example that was not provided in the document. It's not a real issue but it might be confusing/discouraging to new readers trying to reproduce the provided example. I'm referring to the function extract_one_draw (Page 16 in the PDF version), or this chunk here:

y <- extract_one_draw(fake_data)$y
hello_data <- list(N=N, x=x, y=y)

The function extract_one_draw is not defined anywhere in the HTML/PDF version, but I found the chunk here and here and here:

options(htmltools.dir.version = FALSE)
options(digits = 2)
library(knitr)
knitr::opts_chunk$set(cache = TRUE)
knitr::opts_chunk$set(tidy = FALSE, cache.extra = packageVersion('tufte'))
knitr::opts_chunk$set(comment = "")
print_file <- function(file) {
  cat(paste(readLines(file), "\n", sep=""), sep="")
}
extract_one_draw <- function(stanfit, chain = 1, iter = 1) {
  x <- get_inits(stanfit, iter = iter)
  x[[chain]]
}
library("arm")
library("rstan")
options(mc.cores = parallel::detectCores())
rstan_options(auto_write = TRUE)

This file looks like the newest version of the introduction and also does not include the function definition, which is therefore not included in the respective HTML/PDF file. I guess it was moved here.

The knitr-options in all the .Rmd files are {r setup, include=FALSE, echo=FALSE} for the above chunk. I don't really know which exact file the PDF/HTML version on the mc-stan-website is based on but I guess this issue could be easily solved by defining the function in an include = T, echo = T chunk, like the one the function is called in (maybe this one).

I hope I didn't make any mistakes or reproduced an issue or overlook anything. Thank you for creating such accessible documentation for this great software!

PS: I opened this issue before in the wrong repository (https://github.com/stan-dev/example-models) and am re-opening it here. Sorry for the mix-up

Summary:

There is an inconsistency between the data only restrictions for the arguments to the ODE integrators between what is described in the manual and what is actually implemented in Stan.

Description:

Currently, the third and fourth arguments to all ODE integrators are enforced to be data only by the Stan type checker. However, nothing is said about that in the manual.

Reproducible Steps:

Try to compile the model

functions {
  real[] sho(real t,
             real[] y, 
             real[] theta,
             real[] x,
             int[] x_int) {
    real dydt[2];
    dydt[1] = y[2];
    dydt[2] = -y[1] - theta[1] * y[2];
    return dydt;
  }
}
data {
  int<lower=1> T;
  real y0_d[2];
  real ts[T];
  real theta_d[1];
  real x[0];
  int x_int[0];
}
parameters {
  real t0;
  real y0_p[2];
  real theta_p[1];
}
model {
  real y_hat[T,2];
  y_hat = integrate_ode_rk45(sho, y0_d, t0, ts, theta_d, x, x_int);
  y_hat = integrate_ode_rk45(sho, y0_d, t0, ts, theta_p, x, x_int);
  y_hat = integrate_ode_rk45(sho, y0_p, t0, ts, theta_d, x, x_int);
  y_hat = integrate_ode_rk45(sho, y0_p, t0, ts, theta_p, x, x_int);
  y_hat = integrate_ode_rk45(sho, y0_d, t0, ts, theta_d, x, x_int, 1e-10, 1e-10, 1e8);
  y_hat = integrate_ode_rk45(sho, y0_d, t0, ts, theta_p, x, x_int, 1e-10, 1e-10, 1e8);
  y_hat = integrate_ode_rk45(sho, y0_p, t0, ts, theta_d, x, x_int, 1e-10, 1e-10, 1e8);
  y_hat = integrate_ode_rk45(sho, y0_p, t0, ts, theta_p, x, x_int, 1e-10, 1e-10, 1e8);
}
generated quantities {
  real y_hat[T,2];
  y_hat = integrate_ode_rk45(sho, y0_d, t0, ts, theta_d, x, x_int);
  y_hat = integrate_ode_rk45(sho, y0_d, t0, ts, theta_p, x, x_int);
  y_hat = integrate_ode_rk45(sho, y0_p, t0, ts, theta_d, x, x_int);
  y_hat = integrate_ode_rk45(sho, y0_p, t0, ts, theta_p, x, x_int);
  y_hat = integrate_ode_rk45(sho, y0_d, t0, ts, theta_d, x, x_int, 1e-10, 1e-10, 1e8);
  y_hat = integrate_ode_rk45(sho, y0_d, t0, ts, theta_p, x, x_int, 1e-10, 1e-10, 1e8);
  y_hat = integrate_ode_rk45(sho, y0_p, t0, ts, theta_d, x, x_int, 1e-10, 1e-10, 1e8);
  y_hat = integrate_ode_rk45(sho, y0_p, t0, ts, theta_p, x, x_int, 1e-10, 1e-10, 1e8);
}

or

functions {
  real[] sho(real t,
             real[] y, 
             real[] theta,
             real[] x,
             int[] x_int) {
    real dydt[2];
    dydt[1] = y[2];
    dydt[2] = -y[1] - theta[1] * y[2];
    return dydt;
  }
}
data {
  int<lower=1> T;
  real y0_d[2];
  real t0;
  real theta_d[1];
  real x[0];
  int x_int[0];
}
parameters {
  real ts[T];
  real y0_p[2];
  real theta_p[1];
}
model {
  real y_hat[T,2];
  y_hat = integrate_ode_rk45(sho, y0_d, t0, ts, theta_d, x, x_int);
  y_hat = integrate_ode_rk45(sho, y0_d, t0, ts, theta_p, x, x_int);
  y_hat = integrate_ode_rk45(sho, y0_p, t0, ts, theta_d, x, x_int);
  y_hat = integrate_ode_rk45(sho, y0_p, t0, ts, theta_p, x, x_int);
  y_hat = integrate_ode_rk45(sho, y0_d, t0, ts, theta_d, x, x_int, 1e-10, 1e-10, 1e8);
  y_hat = integrate_ode_rk45(sho, y0_d, t0, ts, theta_p, x, x_int, 1e-10, 1e-10, 1e8);
  y_hat = integrate_ode_rk45(sho, y0_p, t0, ts, theta_d, x, x_int, 1e-10, 1e-10, 1e8);
  y_hat = integrate_ode_rk45(sho, y0_p, t0, ts, theta_p, x, x_int, 1e-10, 1e-10, 1e8);
}
generated quantities {
  real y_hat[T,2];
  y_hat = integrate_ode_rk45(sho, y0_d, t0, ts, theta_d, x, x_int);
  y_hat = integrate_ode_rk45(sho, y0_d, t0, ts, theta_p, x, x_int);
  y_hat = integrate_ode_rk45(sho, y0_p, t0, ts, theta_d, x, x_int);
  y_hat = integrate_ode_rk45(sho, y0_p, t0, ts, theta_p, x, x_int);
  y_hat = integrate_ode_rk45(sho, y0_d, t0, ts, theta_d, x, x_int, 1e-10, 1e-10, 1e8);
  y_hat = integrate_ode_rk45(sho, y0_d, t0, ts, theta_p, x, x_int, 1e-10, 1e-10, 1e8);
  y_hat = integrate_ode_rk45(sho, y0_p, t0, ts, theta_d, x, x_int, 1e-10, 1e-10, 1e8);
  y_hat = integrate_ode_rk45(sho, y0_p, t0, ts, theta_p, x, x_int, 1e-10, 1e-10, 1e8);
}

Both should be correct, according to the manual, but the Stan compiler complains that the third/fourth argument to ODE solvers should be data only. The same happens for other ODE solvers.

Current Output:

The current output. Knowing what is the current behavior is useful.

Expected Output:

I do not know which of the two is correct, but the inconsistency should be resolved.

Current Version:

v2.18.0

Summary:

Write documentation for standalone function compilation.

Description:

When #2267 was implemented and merged, only rudimentary documentation was created. Some description in both manual and the stanc command line is desirable.

Current Version:

v2.15.0

Summary:

The src code for the manual includes GLM functions, but online docs don't - regenerate from src.

Description:

see issue #30

Additional Information:

src for manual includes description of real var constraints offset/multiplier - this should be left out of 2.18 release.

Current Version:

v2.18.0

Summary:

Update the manual to indicate initial time and time can now be passed as var in the ODE functions. See stan-dev/stan#2757.

Current Version:

v2.18.0

Summary:

The currently hosted version of the Stan book does not have any internal version numbering. The document should have version numbers.

Description:

https://mc-stan.org/docs/bayes-stats-stan/index.html

There's an older version with version number that @andrewgelman posted on his personal site (I'm not going to link and compound the google indexing problem with that version).

Current Version:

16 December 2018