David Widmann

> For Chains the corresponding methods live in Turing proper. That might be cleaner. There have been long discussions (and even issues IIRC, maybe even in DynamicPPL?) about how messy...

> How would you recommend proceeding then for this integration? I guess short-term basically anything goes - it can just take a long time to move away and improve a...

Thank you for the PR! My general feeling though is that we should not re-invent and re-implement numerical algorithms that already exist and are better maintained in other packages such...

As a general comment before any detailed review: > the rand-n version is faster for both models Can we test different number of samples? n = 10000 is a bit...

Given that chains support the Tables interface, maybe users should be pointed towards AlgebraOfGraphics as the easiest (but still customizable) way for plotting chains with Makie?

> https://github.com/JuliaStats/Distributions.jl/issues/1907 is related. https://github.com/JuliaStats/Distributions.jl/pull/1905/commits/17154a2c1e38050f3c864b3e93f1b8cd496f45a8 fixes it.

> its return type should be predictable by knowing what d is I became convinced that in general this is not possible. It basically means trying to manually figure out...

The reason is that for quite a few of the older, probably less used and definitely less frequently updated distributions the `rand` implementation contains hardcoded `Float64`, either as literals or...

I think this might be an upstream issue but I'm not too familiar with Malt so maybe it's intended and/or could be avoided: ```julia julia> using Malt julia> w =...

Hmm, the RNG object id seems to be stable, so it seems to be the same RNG? ```julia julia> Malt.remote_eval_fetch(w, quote objectid(Random.default_rng()) end) 0xffffffff0968f0b4 julia> Malt.remote_eval_fetch(w, quote objectid(Random.default_rng()) end) 0xffffffff0968f0b4...