Closed devmotion closed 1 year ago
Sorry, but isn't this a breaking change? Prior to this PR, you didn't have to implement the LogDensityProblems-interface; you could still just provide a callable that represented the logdensity. It seems like this is no longer possible?
No, I don't think so. Already prior to this PR in AdvancedHMC 0.4, Hamiltonian(metric, lp)
required that lp
supported LogDensityProblems.logdensity
. Arbitrary callables were only supported in the Hamiltonian(metric, lp, lp_and_grad)
constructor which is not affected by this PR.
The main changes in this PR were:
model::LogDensityModel
in exactly the same way as if model.logdensity
would have been provided
model.logdensity
required support of gradient evaluation whereas it was fine to provide a "vanilla" log density without gradient capabilitiesHamiltonian(metric, model::LogDensityModel, ::Union{Val,Symbol})
was supported whereas Hamiltonian(metric, logdensity, ::Union{Val,Symbol,Module})
also supported Module
sLogDensityProblems.capabilities
to provide more meaningful error messages.In principle, in a follow-up PR we could re-add support for callables which was removed in AdvancedHMC 0.4: If LogDensityProblems.capabilities(logdensity) === nothing
, we could assume the provided logdensity
is a function.
This PR proposes some changes of the
Hamiltonian
constructors:logdensity_and_gradient
) an AD backend is not used automatically but only if explicitly specifiedLogDensityModel
s are handled in the same way as if only their log density would have been provided, ie, in particular ForwardDiff is used automatically if the log density does not support computation of the gradient