Overloading PosteriorStats methods

[sethaxen]

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 with PosteriorStats.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 with PosteriorStats.hdi.
  • ArviZ renamed hpd to hdi 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.
  • PosteriorStats also uses a default interval probability of 0.94. As McElreath argues, any default is arbitrary and using a "non-standard" probability encourages the user to think about the interval they select and avoids potential confusion for those coming from a more frequentist background. McElreath recommends 0.89 for no reason than because it's prime. Its estimates are also more stable with low sample size. We use 0.94 because it's more conservative.

This would introduce several new functions:

• r2_score
• loo_pit
• loo
• waic
• compare

~A loo method is also defined and exported by ParetoSmooth, so if loo 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 maybe loo_pit for Chains inputs.

cc @ParadaCarleton @devmotion

[devmotion]

A loo method is also defined and exported by ParetoSmooth, so if loo 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.

[sethaxen]

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.