David Widmann

Fundamentally, it seems Chains is the wrong datastructure for such operations since it encodes the array structure only in the parameter names but parameter names can be changed freely and...

BTW I just learnt about https://github.com/JuliaArrays/AxisArrays.jl/issues/182 some days ago (while reviewing the DiffEq tutorial), which is pretty bad - indexing by names will give surprising results (and probably lead to...

Maybe we should consider switching to https://github.com/mcabbott/AxisKeys.jl soon while still thinking about other data formats such as StructArrays which might sometimes be more suitable?

@phipsgabler ChainDataFrames implements the Tables interface, so at least it should be easy to convert it to a Vector of NamedTuples or a NamedTuple of Vectors by running `Tables.rowtable` and...

You mean by saving it in the AxisArray? Similar to all the Turing statistics and other additional parameters, this could lead to name conflicts with "actual" parameters but in this...

Actually, I think that one could even consider separating the actual parameters and all the metadata/statistics into different arrays to avoid these problems in the current implementation.

The fundamental problem is that MCMCChains should not depend on DynamicPPL. But I assume one could/should work around this problem by moving some of the interface in DynamicPPL to AbstractMCMC...

`aic` etc. are defined in StatsBase: https://github.com/JuliaStats/StatsBase.jl/blob/2faa6e80b7966b915086d8cd5a4a4d89a2126db5/src/statmodels.jl#L192 I think `dic` etc. should be defined in a similar way if possible: there's some lightweight functional interface (such as `loglikelihood`) and if...

BTW just recently also a pointwise loglikelihood `loglikelihood(model, observation)` (with `loglikelihood(model, :)` for all observations) was added: https://github.com/JuliaStats/StatsBase.jl/pull/685

Yes, and then one would just make sure that `StatsBase.loglikelihood(::MCMCModel)` etc. are implemented. Since e.g. in DynamicPPL we don't want to subtype StatisticalModel (there's already a different supertype), one could...