-
Notifications
You must be signed in to change notification settings - Fork 9
Description
Motivation
Suppose that for a set of parameters
Theoretically, one could of course solve for the
then
would be a good initial guess for
Ideally, "users" like Turing.jl and DynamicHMC.jl should be able to ignore the details of these things and just carry on doing HMC/NUTS/etc with minimal changes.
Proposal: allow coordinates to be opaque
I propose an addition to the API composed of 3 functions, with the fallbacks
lift(ℓ, x::AbstractVector) = x
unlift(ℓ, x::AbstractVector) = x
translate(ℓ, x::AbstractVector, Δ::AbstractVector) = x .+ Δ
Specifically,
- "users" would call
lift
when generating random points for starting MCs, and in similar situations. Otherwise they would usetranslate
, - similarly,
unlift
would be called when coordinates are needed (eg turn statistics), - leapfrog and RWMH steps would use
translate
. - otherwise the result of
lift
and thex
arguments oflogdensity
,logdensity_and_gradient
,translate
,unlift
are allowed to be opaque objects, not an::AbstractVector
of real numbers. Nevertheless,logdensity_and_gradient
should provide a valid gradient ofx -> logdensity(ℓ, lift(ℓ, x))
, but how that is done is up to the implementation ofℓ
.
Bikeshedding names is appreciated 😉, also alternative API suggestions.
How this meshes with AD
This is a bit tricky and I don't yet have a good API in mind. Related work is in