David Widmann

There is already a related open issue in Bijectors: https://github.com/TuringLang/Bijectors.jl/issues/134#issuecomment-679096131

> I think this is somewhat more involved than the suggestion in TuringLang/Bijectors.jl#134 (comment). Sure, it requires the LKJCholesky distribution and the bijector, and support for Cholesky factors in whatever...

It's mentioned in the OP, together with a link to https://github.com/cscherrer/MeasureTheory.jl/issues/100.

No, it's not natively supported but I would prefer samples of type `Cholesky` nevertheless. I guess we can always fall back to storing the full matrix or some other linearization...

Oh I missed that this was not the ossue in Distributions. I'll reopen 😄

LKJCholesky is available in Distributions 0.25.20. However, as discussed above, support for it in Turing requires (probably major) changes in Bijectors and DynamicPPL, so it will take a while until...

This distribution operates with and samples `Cholesky` object and therefore a new `CholeskyVariate` was introduced in Distributions. As far as I can see, the main problems are - Bijectors currently...

@sethaxen It is definitely possible to ignore the current assumptions in the Bijectors API and just implement a bijection by reusing the existing code for `LKJBijector`. But this will break...

It seems the problem is https://github.com/JuliaStats/StatsBase.jl/blob/1c3f3d7ae4fd8afae126443d15ddaf8029316618/src/statmodels.jl#L468. I assume it should be changed to ```julia mat = [j == 1 ? rownms[i] isa AbstractString ? NoQuote(rownms[i]) : rownms[i] : ``` BTW...

Isn't the reference particle always the last particle in the container, i.e., `pc.vals[end]` in a container `pc`? So I'm thinking maybe it would be more natural to have two implementations...