Add a `logdensity` specialization that takes `NamedTuple`s

[Red-Portal]

As discussed on Slack, it would be good to have an additional specialization of logdensity that takes NamedTuple-valued inputs. The Turing main repo already implements this as boilerplate for AdvancedMH, so it would be nice to have an official unified implementation that also supports AD.

Right now, it seems to me that adding a specialization to unflatten would do the job. (And maybe change the function's name to something else since it is not doing unflatten anymore?)

[devmotion]

A prior discussion (I don't remember the details): #501

[Red-Portal]

Hi @yebai , could chime in on what we should do here?

[yebai]

There are other parts of AbstractMCMC that would benefit from a more general form of logdensity (ℓ, ...) which doesn't assume the second argument is a vector of reals, so it is worth considering how we can consistently handle this. We should probably take a look at something more recent for specifying interfaces and see whether we could have a LogDensityProblem 2.0:

https://github.com/rafaqz/Interfaces.jl

cc @willtebbutt and @sunxd3

[Red-Portal]

@devmotion Any additional thoughts?

[penelopeysm]

DynamicPPL 0.38 lets you do this:

julia> using DynamicPPL, Distributions

julia> @model function f()
           x ~ Normal()
           y ~ Normal(x)
       end
f (generic function with 2 methods)

julia> m = f(); v = VarInfo(m);

julia> DynamicPPL.getlogjoint(last(DynamicPPL.init!!(m, v, DynamicPPL.InitFromParams((x = 0.5, y = 1.5)))))
-2.4628770664093453

julia> logpdf(Normal(), 0.5) + logpdf(Normal(0.5), 1.5)
-2.4628770664093453

In the short term, this is easy enough to wrap in a function, so I'll close this issue.

In the long term, I think it's a bit dangerous to allow logdensity to be called with things that it's not meant to be called with. This creates a 'secret interface' that only DynamicPPL users can make use of: see 'A problem with interface packages' in https://invenia.github.io/blog/2020/11/06/interfacetesting/. If we wanted to do this, the long-term solution would be to stop using LogDensityProblems.jl as an interface and make a new one. See #880 for discussion.

[Red-Portal]

Hi @penelopeysm , I think in the long term, it would be ideal for LogDensityProblems to officially support NamedTuple-valued variables, especially since Distributions.jl officially has that.

[penelopeysm]

Sure, but LDP is not a Turing repo.