Similar to the tutorial on custom losses in SVI, we should have a tutorial on implementing custom MCMC kernels using the new MCMC API. Something simple like SGLD seems like a good starting point.

Summary:

There is a mismatch between implementation and doc in signatures of falling_factorial and rising_factorial. The language restricts the second argument to be integer, but this is not documented. Also, log_falling_factorial and log_rising_factorial do not have this restriction. Is that intentional?

Description:

See above.

Reproducible Steps:

Try to compile

Ankit Shah and I are trying to use Gen to support a project and would love the addition of a dirichlet distribution

This looks really awesome and would love to get started with this. Is there an official docs page?

the links in the README pull up HTML pages that seem to be missing images for the models.

Perhaps I could convert them to markdown/latex cells so they'll guarantee rendering?

Love this repo, by the way. Writing a software library (and demos for it) based on my thesis work in inverse problems, and this helps motivate what "good tutorials" can look like.

@bgoodri I just noticed that none of the CRAN versions of the vignettes have any output from the code chunk no output anymore (e.g. if you look at https://cran.r-project.org/web/packages/rstanarm/vignettes/count.html
or any of the other vignettes). That is, it looks like none of the code is getting evaluated. I know that we're using that mechanism with params$EVAL to avoid evaluating the vignet

Here there is an example for pymc3 where they do exactly that.

https://docs.pymc.io/notebooks/howto_debugging.html

Just noticed that this isn’t discussed anywhere, but the PPC functions have always also been very useful for prior predictive checking, not just posterior checking.

Hi,
Thanks for the great package!
I was trying to understand the default prior placed on noise standard deviation (I suppose that is what the last few hyper-parameters mean in the code?
When I played around with the scale parameter of the implemented horseshoe prior, I think the distribution

Agree with the aliasing.

If I understand you, we'd have:

• Against point null:
  • p_map (which is prob at MAP vs. prob at 0)
  • bf_zero (= bf_savagedickey)
• Against ROPE
  • p_rope (= rope(..., ci = 1))
  • bf_rope
• Against direction
  • p_direction
  • bf_direction
• Against region of practical significance (i.e., ROPE * direction)
  • p_significance
  • `b

Add a new tab for displaying user's personal plots. They can add plots by

• pointing shinyStan to a ggplot2 object in their R global environment
• uploading .RData file containing a ggplot2 object
• upload an image (e.g. png, etc.)

Question and context

This obviously isn't a bug, but I'm trying to work out the logic behind why print.report_table requires nested calls to both insight, and then parameters. There's something I've missed along the way in terms of why format table is contained within insight if it's used for pretty printing. Indeed, this could have been discussed in another thread and I've missed i

rand_phasepoint should pass the point q to rand. i.e. https://github.com/tpapp/DynamicHMC.jl/blob/65f8a30ed0cc74c26206dcbbdc6dee91629dfddf/src/hamiltonian.jl#L157
should be

rand_phasepoint(rng::AbstractRNG, H, q) = phasepoint_in(H, q, rand(rng, H.κ, q))

This is consistent with the existing interface for rand used in

https://github.com/tpapp/DynamicHMC.jl/blob/65f

The documentation for "Creating new PFTs" in the ["web workflow" section](https://pecanproject.github.io/pecan-documentation/develop/web-workflow.html#web-model-config, section 5.2.2.2) is misleading,. As written, it's not clear that you need to open BETY first (it looks like you can just do it from the PEcAn web interface, which is not true).

I propose we move it to a dedicated section on th

From Lu Cheng:

"It was said in GPStuff manual page 42 that periodic kernel was coming
from this paper
http://jmlr.org/proceedings/papers/v33/solin14.pdf

In page 907, equation (23) and GPStuff appendix, there is the canonical
periodic covariance function. And it is not obvious to find the explicit
form of quasi-periodic covariance function in section 3.5.

In the demo_periodic.m, there is alway t