New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

next manual, 2.18(++) #2552

Open
bob-carpenter opened this Issue Jun 16, 2018 · 22 comments

Comments

Projects
None yet
6 participants
@bob-carpenter
Contributor

bob-carpenter commented Jun 16, 2018

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

@bob-carpenter bob-carpenter added this to the 2.17.1++ milestone Jun 16, 2018

@bob-carpenter bob-carpenter self-assigned this Jun 16, 2018

@bob-carpenter

This comment has been minimized.

Contributor

bob-carpenter commented Jun 16, 2018

  • In thematrix_exp_multiply function doc, the expanded form should read \farg{t} * \farg{A}.
@jrnold

This comment has been minimized.

Contributor

jrnold commented Jul 3, 2018

  • Figure 23.1: Update note: "cholesky_factor_cov[K] ... are only assignable to matrices of dimensions matrix[K, K]. Update to account for generalization of choleskey_factor_cov to rectangular matrices. Perhaps update the cholesky_factor_cov row in the table. I searched for choelesky_factor_cov in the manual and didn't see any other cases in which it was stated that the matrix must be square for this type.
@bob-carpenter

This comment has been minimized.

Contributor

bob-carpenter commented Jul 3, 2018

@jrnold

This comment has been minimized.

Contributor

jrnold commented Jul 5, 2018

Okay, I read it as still implying that cholesky_factor_cov itself has to be square; and the table itself doesn't have any mention of a non-square cholesky _factor_cov.

@ihincks

This comment has been minimized.

ihincks commented Jul 11, 2018

In the subsection “Correlation Matrix Inverse Transform”: It reads that tanh maps into (0,1), but I think it should read (-1,1).

@bob-carpenter

This comment has been minimized.

Contributor

bob-carpenter commented Jul 12, 2018

Thanks, @ihincks. I'll fix that for 2.19, which should be out soon. 2.18 should be released in a few days, then we are targeting a mid-August release of 2.19.

@seantalts seantalts modified the milestones: 2.18.0, 2.18.0++ Jul 13, 2018

@bob-carpenter

This comment has been minimized.

Contributor

bob-carpenter commented Jul 19, 2018

  • Remove the doc for abs because it's not vectorized (or vectorize it, but that's not a doc issue).

This came up with a post of @andrewgelman's on the forums

@bob-carpenter

This comment has been minimized.

Contributor

bob-carpenter commented Jul 19, 2018

  • explain why hierarchical models don't have MLEs other than when given zero-avoiding priors
@bob-carpenter

This comment has been minimized.

Contributor

bob-carpenter commented Jul 20, 2018

  • Qualify the statement "The Stan interfaces provide a mechanism for specifying a sequence of system paths in which to search for include files." to say "may provide".
@bob-carpenter

This comment has been minimized.

Contributor

bob-carpenter commented Jul 20, 2018

From a forum question of aornugent's

The output of each mapped function is concatenated to produce the output of map_rect.

Will this be concatenated in the same order as the sharded input data, or by whichever worker terminates first?

  • clarify that it's the order of the inputs
@jjramsey

This comment has been minimized.

Contributor

jjramsey commented Aug 8, 2018

I noticed that in the Stan functions reference, the documentation for the *_rng functions still says that they can only be used in the generated quantities block, even though they now can be used in the transformed data block as well (http://andrewgelman.com/2017/06/16/stan-weekly-roundup-16-june-2017/).

@bob-carpenter

This comment has been minimized.

Contributor

bob-carpenter commented Aug 9, 2018

Thanks, @jjramsey --- I'll fix.

@jjramsey

This comment has been minimized.

Contributor

jjramsey commented Aug 16, 2018

There are some Markdown errors in the new reference manual. On page 28, after the heading "Array index style" is the text "{#array-index-style.footnote}". On page 131, instead of "Variable declarations and compound definitions" appearing in a header font, it just appears as the text "### Variable declarations and compound definitions {-}".

@jjramsey

This comment has been minimized.

Contributor

jjramsey commented Aug 20, 2018

There's a very minor issue with the users' guide PDF. In the section "Priors for length-scale", it reads "In this case, an inverse gamma, inv_gamma_lpdf in StanâAZs language, will work well", where the part that reads "StanâAZs language" is a bit garbled. It looks like the problem is that in the LaTeX source file examples.tex, the apostrophe in "Stan's" is represented by a Unicode "RIGHT SINGLE QUOTATION MARK" (code point U+2019) instead of an ASCII apostrophe.

@bob-carpenter

This comment has been minimized.

Contributor

bob-carpenter commented Aug 20, 2018

Thanks, @jjramsey. That'll be easy to fix. I should do a general search for non-ASCII characters.

@bob-carpenter

This comment has been minimized.

Contributor

bob-carpenter commented Aug 23, 2018

Originally from @ryan-richt onn #2617

I'm not sure what the rest of the sentence is supposed to be, but the suspense is killing me ;-)

FYI:

defined as a local variable within the model block if

PS. I tried instead to follow this link from the contributing guidelines, but it shows zero such open issues:

https://github.com/stan-dev/stan/issues?utf8=%E2%9C%93&q=is%3Aopen%20label%3ABug%20%22next%20manual%22%20label%3ADocumentation

@bob-carpenter

This comment has been minimized.

Contributor

bob-carpenter commented Sep 6, 2018

Add Ben's suggestion for truncated RNGs:

https://discourse.mc-stan.org/t/rng-for-truncated-distributions/3122/7?u=bgoodri

We could potentially generalize using the algebraic solver to compute general inverse CDFs, but I haven't tried it. There's more advice on doubly truncated things from @nschiett in:

stan-dev/math#214 (comment)

@bob-carpenter

This comment has been minimized.

Contributor

bob-carpenter commented Sep 19, 2018

From @avehtari on #2639:

The reference manual reference-manual-2.18.0.pdf downloaded from
https://github.com/stan-dev/stan/releases/download/v2.18.0/reference-manual-2.18.0.pdf

  • is missing some text at the end of page 153
  • Figure 14.1 is on page 153, but the caption is on page 152

(these are probably due switch to bookdown, but I don't know how to fix these)

@bob-carpenter

This comment has been minimized.

Contributor

bob-carpenter commented Sep 20, 2018

  • create a map_rect example that has different sizes for x and y.

  • write a simple version that groups by single element and deals with one output and three predictors

@bob-carpenter

This comment has been minimized.

Contributor

bob-carpenter commented Sep 22, 2018

From DouglasBoubert in this discourse thread reported:

The user guide (stan-reference-2.17.0.pdf) describes the inc_beta function as being the first integral in section F.2. Stan actually implements the inc_beta function as the second integral, i.e. as the regularised incomplete beta function.

This is the same design choice made in several other languages (for instance, scipy implements it this way), but

  • the documentation should make this clear!
@mitzimorris

This comment has been minimized.

Member

mitzimorris commented Sep 26, 2018

could you please make the language in the reference manual w/r/t reserved words and variable names completely unambiguous - I was confused by this one:

Variable names will not conflict with the following block identifiers,

functions, model, data, parameters, quantities,
transformed, generated

I interpreted "will not conflict" in the opposite way from its intended meaning - i.e., I thought that you could name variables data and that wouldn't be a conflict. how about the following:

The following block identifiers are reserved and cannot be used as variable names:
@bob-carpenter

This comment has been minimized.

Contributor

bob-carpenter commented Oct 17, 2018

  • update http:// links to https:// for mc-stan.org, github.com, and discourse.mc-stan.org.

This was originally submitted by @junpenglao as PR #2624 before the docs were moved to R markdown.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment