stan-dev / docs Goto Github PK
View Code? Open in Web Editor NEWDocumentation for the Stan language and CmdStan
Home Page: https://mc-stan.org/docs/
License: Other
Documentation for the Stan language and CmdStan
Home Page: https://mc-stan.org/docs/
License: Other
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.
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}
.
v2.19.0
Moved from @lamhm's stan-dev/stan issue stan-dev/stan#2771.
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).
v2.19.1
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.
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'.
v2.18.0
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 /.
We need to update the manual to list the precedence of ./ and .* to be the same as * and / (so less tight binding than \ ).
Provide any additional information here.
v2.18.0
qr_R doc text has an error
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"
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.
v2.18.0
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).
I'm writing up changes to the manual to add the new signatures for log_mix
(as in stan-dev/stan#2532).
(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'?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?v2.17.1
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.
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}
v2.19.0
Looking at the code and examples, I think that the following holds:
varname[i,j,k]
appear as varname.i.j.k
in the CSV header line,varname
, the range of colums is contiguous, ie one cannot have a.1, b, a.2
columns in the posterior 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.
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.
v2.19.0
review regression chapter - recommendation for half Cauchy should be half Normal or whatever latest "fatwah" (Andrew's words).
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.
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.
Please provide a short couple sentence summary.
Describe the issue as clearly as possible.
Provide any additional information here.
v2.18.0
Descriptions about how to use new covariance functions.
Additions IBNLT
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.
v2.19.0
Write documentation for standalone function compilation.
When #2267 was implemented and merged, only rudimentary documentation was created. Some description in both manual and the stanc command line is desirable.
v2.15.0
Update the manual to indicate initial time and time can now be passed as var in the ODE functions. See stan-dev/stan#2757.
v2.18.0
this issue should be used to note all broken or missing cross-references for this docset.
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.
v2.18.0
Copied from original issue: stan-dev/stan#2707
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.
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
cross-reference to section in user's guide?
v2.18.0
1D Integrator: No documentation
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).
v2.18.0
This is the place to record typos and brainos or suggestions for the manual.
v2.18.1
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
v2.18.0
document the addition of adam-moulton ODE solver
https://discourse.mc-stan.org/t/ode-roadmap-different-solvers/8766/4
Provide any additional information here.
v2.18.0
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.
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:
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.
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
}
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.
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.
v2.18.0
The currently hosted version of the Stan book does not have any internal version numbering. The document should have version numbers.
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).
16 December 2018
As mentioned in the Discourse thread here we should add a section on determinism in scientific computing (numerical reproducibility).
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.
/
v2.18.0
The hyperlink to the section Priors for Gaussian Process Parameters in the users guide for 2.18 is not working.
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.
Provide any additional information here.
v2.18.0
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.
v2.17.1
Basic rendering bug in 12.1.1-3
This does not have pretty math in my browser (Firefox ESR):
https://mc-stan.org/docs/2_18/functions-reference/binomial-distribution.html
v2.18.0
Conversion from latex to Rmd failed to register signatures some functions. also missing entries for sampling statements for distributions.
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
v2.19.0
The doc should indicate the precision of the ASCII output.
Longer term, we'll want to control the precision, but now it's fixed and we should mention what it is.
v2.17.1
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?)
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.
The src code for the manual includes GLM functions, but online docs don't - regenerate from src.
see issue #30
src for manual includes description of real var constraints offset/multiplier
- this should be left out of 2.18 release.
v2.18.0
markdown code includes png (speeds up build), but we don't
have the R code checked in which generates these images.
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)
Provide any additional information here.
v2.18.0
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.
v2.18.0
Please provide a short couple sentence summary.
Describe the issue as clearly as possible.
Provide any additional information here.
v2.18.0
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.
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.
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.
The current output. Knowing what is the current behavior is useful.
I do not know which of the two is correct, but the inconsistency should be resolved.
v2.18.0
Update manual so there is:
Return codes for the executable for compiled Stan programs are not defined. Define them and add them to the CmdStan documentation.
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.
v2.19.1
Currently, lp__ still appears in the reference manual as being deprecated. However, it has already been removed from the language.
lp__ should be removed from the deprecated features list in the reference manual.
v2.18.0
HTML link incorrect
link in sparse-matrices.html to csr.html should be CSR.html
Problem is probably due to developing on a case preserving filesystem (mac, windows)
but deploying on a case sensitive filesystem (linux)
v2.18.0
Sec 2.1 on Autoregressive models contains a minor error in the description of AR(1) models.
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)$
v2.18.0
The table referenced in section 9.4 ("Coding Ragged Arrays") is present in the PDF output but not the HTML output.
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).
The table missing is:
docs/src/stan-users-guide/clustering.Rmd
Lines 258 to 273 in 90cb5fd
v2.19
"id: " tags are printed in PDF of User Guide v2.19, ODE section
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.
v2.19.0
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.
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
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.
/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.
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.
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:
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.
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.
Equation for sampling distribution of h_t
has a typo.
Both the RHS and LHS of recurrence equation
docs/src/stan-users-guide/time-series.Rmd
Line 519 in bd1efae
use h_t. RHS should be using h_t-1
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
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.
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/ .
Provide any additional information here.
v2.18.0
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.