Open sethaxen opened 1 year ago
A
loo
method is also defined and exported by ParetoSmooth, so ifloo
is also exported by MCMCChains, this would cause namespace collisions. We should discuss how we want to handle this.
julia> using MCMCChains
julia> :loo in names(MCMCChains; all=true, imported = true)
false
So loo
is neither exported nor imported in MCMCChains.
No, loo
is exported by PosteriorStats. But actually, on second thought there'd be no benefit in overloading loo
for Chains
, since its input is an array of log-likelihood values that wouldn't be stored in Chains
anyways.
As discussed on the Turing Slack, MCMCChains should overload methods defined in ArviZ's PosteriorStats for
Chains
inputs, similar to how it overloads methods in MCMCDiagnosticTools.This would introduce some breaking changes:
MCMCChains.summarize
would be replaced withPosteriorStats.summarize
. The returned object would similarly be a table, but the API is different enough that this would be breaking.MCMCChains.hpd
would be replaced withPosteriorStats.hdi
.hpd
tohdi
some time ago because it a strictly more descriptive name. The HDI is a distributional property, appropriate for both priors and posteriors, but also other distributions. A deprecation warning can be used here.This would introduce several new functions:
r2_score
loo_pit
loo
waic
compare
~A
loo
method is also defined and exported by ParetoSmooth, so ifloo
is also exported by MCMCChains, this would cause namespace collisions. We should discuss how we want to handle this.~EDIT: Of these functions, it probably only makes sense to overload
r2_score
and maybeloo_pit
forChains
inputs.cc @ParadaCarleton @devmotion