-
Notifications
You must be signed in to change notification settings - Fork 226
Provide AD gradient for MLE/MAP #1369
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 4 commits
da777ba
fc2f8df
284bbdf
2ddd480
5ecc065
959ff51
f431e2b
53d9134
fa7c59f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -147,6 +147,50 @@ function (f::OptimLogDensity)(z) | |
return -DynamicPPL.getlogp(varinfo) | ||
end | ||
|
||
function (f::OptimLogDensity)(F, G, z) | ||
spl = DynamicPPL.SampleFromPrior() | ||
|
||
|
||
if G !== nothing | ||
cpfiffer marked this conversation as resolved.
Show resolved
Hide resolved
|
||
# Calculate log joint and the gradient | ||
l, g = gradient_logp( | ||
z, | ||
DynamicPPL.VarInfo(f.vi, spl, z), | ||
f.model, | ||
DynamicPPL.SampleFromPrior(), | ||
f.context | ||
) | ||
|
||
# Use the negative gradient because we are minimizing. | ||
G[:] = -g | ||
|
||
# If F is something, return that since we already have the | ||
# log joint. | ||
if F !== nothing | ||
F = -l | ||
return F | ||
end | ||
end | ||
|
||
# No gradient necessary, just return the log joint. | ||
if F !== nothing | ||
F = f(z) | ||
return F | ||
end | ||
|
||
return nothing | ||
end | ||
|
||
function (f::OptimLogDensity)(F, G, H, z) | ||
# Throw an error if a second order method was used. | ||
if H !== nothing | ||
error("Second order optimization is not yet supported.") | ||
end | ||
|
||
# Otherwise, just do the function and gradient info. | ||
return f(F, G, z) | ||
end | ||
|
||
""" | ||
ModeResult{ | ||
V<:NamedArrays.NamedArray, | ||
|
@@ -369,6 +413,11 @@ function _optimize( | |
args...; | ||
kwargs... | ||
) | ||
# Throw an error if we received a second-order optimizer. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we have to do that? Doesn't Optim just use ForwardDiff (or FD?) to compute the Hessian in this case? If that's the case, then we shouldn't throw an error IMO. It might not be the most efficient approach and would not adhere to the user-provided AD settings but as long as it works we could only print a warning. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In FD yes; but (for example in the project that I am working on) it could be that users only define custom adjoints for the gradients but not the Hessian. Therefore even the user provides an AD backend, it might not be a great idea if it by default take that for Hessian function. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You mean we shouldn't even print a warning? Would be fine with me as well. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh, I think throwing an error when some Hessian-required optimizer is received is a great idea, just like what Cameron did here. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we want to throw an error if the Hessian is evaluated, I suggest using if H !== nothing
error("second order methods are not supported at the moment")
end In general, this approach is more flexible, avoids baking in a hardcoded check for a special type of a different package in our implementation, and avoids incorrect and unexpected behaviour for second-order optimization algorithms that don't subtype this specific type (since multiple inheritance is not possible in Julia, that's not an impossible scenario per se). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's a bug. I think there might be an issue for it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I just found JuliaNLSolvers/Optim.jl#718, I guess that's the related issue. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I have a fix. Sorry to cossio for waiting a year and a half 😬 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I mean, I will tag a fix in an hour or so, so please don't special case with a branch. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
# if optimizer isa Optim.SecondOrderOptimizer | ||
# throw(ArgumentError("Second order optimizers for MLE/MAP are not yet supported.")) | ||
# end | ||
|
||
# Do some initialization. | ||
spl = DynamicPPL.SampleFromPrior() | ||
|
||
|
@@ -378,9 +427,12 @@ function _optimize( | |
link!(f.vi, spl) | ||
init_vals = f.vi[spl] | ||
|
||
|
||
# Optimize! | ||
M = Optim.optimize(f, init_vals, optimizer, options, args...; kwargs...) | ||
M = if optimizer isa Optim.SecondOrderOptimizer | ||
Optim.optimize(Optim.only_fgh!(f), init_vals, optimizer, options, args...; kwargs...) | ||
else | ||
Optim.optimize(Optim.only_fg!(f), init_vals, optimizer, options, args...; kwargs...) | ||
end | ||
|
||
# Warn the user if the optimization did not converge. | ||
if !Optim.converged(M) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if it's useful to keep this separate definition? It seems we only need
f(F, G, H, z)
, so the implementation could just be included there directly.