David Widmann

Ah, I think it could be https://github.com/JuliaCI/PkgBenchmark.jl/issues/135 which was caused by a Project.toml file that Pkg automatically reformatted, and hence the repo seemed to be dirty in CI. Edit: Although...

Generally, maybe the benchmark setup would be a bit simpler with AirspeedVelocity.jl. But of course either approach should be fine.

Is there an actual problem/conflict with some other package? My initial feeling is that we should only make such a change if it's worth it.

The reason for this observation is that `sampler(Beta(...))` is not type stable: Depending on the parameters, a different algorithm is used for sampling. https://github.com/JuliaStats/Distributions.jl/pull/1350 "fixed" the performance and allocation issues...

> But can it always return the same object The motivation for `sampler` is to precompute algorithm-dependent quantities when drawing multiple variates. The number and type of these quantities are...

> Or a specialized method for rand! for Beta would also solve this issue entirely I still wonder, is there any issue here? It seems the function barrier in #1350...

> To answer your question about the performance, yes, it does affect performance in the following case: The example is a bit contrieved since ideally you would use the `sampler`...

Probably easiest to compare with `BigFloat`s. E.g., on the master branch the example above gives ```julia julia> using Bijectors julia> d = Uniform(big(-1.0), big(1.0)); julia> b = bijector(d); julia> y...

Yes, you can specify the keyword argument `thinning`. All common keyword arguments of AbstractMCMC should work since the general non-sampler specific part of the sampling is implemented in AbstractMCMC: https://turinglang.github.io/AbstractMCMC.jl/dev/api/#Common-keyword-arguments...

@yebai I think this is a Turing.jl/Turing documentation issue, isn't it? As mentioned above, it is already documented in AbstractMCMC: https://beta.turing.ml/AbstractMCMC.jl/dev/api/#Common-keyword-arguments