-
Notifications
You must be signed in to change notification settings - Fork 41
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
Add getparams
and setparams!!
following AbstractMCMC v5.5 and v5.6
#378
Conversation
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
the failed test is not related to this PR, @yebai maybe you already have an answer to why it fails? |
@sunxd3 This is due to some changes in Julia’s handling of script entry functions. Can you try to fix that? |
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.
The current impl is going to lead to incorrect log-density values being used in the transition. IMO we shouuld do the safe thing by default here.
src/abstractmcmc.jl
Outdated
return state.transition.z.θ | ||
end | ||
|
||
function AbstractMCMC.setparams!!(state::HMCState, θ) |
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.
One dangerous aspect there is that state.transition
caches the logjoint and gradient computations. So when you use the @set
macro here, you're going to also keep the cached log-joint and gradient computation, which will then be out of sync with the parameters.
If you then naively pass this transition somewhere, say, into the next step
call, AHMC.jl will use the incorrect logjoint eval in the MH step.
IMO the safe way is to use the explicit constructor of PhasePoint
I believe without passing in the cached values. This should result in receomputation of this.
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.
just realized that model
is not passed into setparams!!
, I think for now, we only set the parameters, then when use the transition, logp should be recomputed. (we can also later introduce some like setlogp
or compute_logp
etc.) I'll add a comment in the code
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.
Agreed with @torfjelde's concern. Can we add logdensitymodel
to
setparams!!(state, logdensitymodel, params)
getparam(state, logdensitymodel)
.
where logdensitymodel
follows the LogDensityProblem
interface. This would allow us to recompute the model's log probability (i.e., recompute_logp
) inside these setparam!!
functions on demand, which Turing's new Gibbs sampler uses.
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Hong Ge <[email protected]>
let's delay a bit to see through TuringLang/AbstractMCMC.jl#150 |
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.
The fix to setparams!!
doesn't work unfortauntely. We need access to the model
here, which we don't have.
IMO we should add model
as an argument to the AbstractMCMC.jl interface. Otherwise there's no way we can do stuff like update the gradient information, which is an issue we're facing both here and in AdvancedMH.jl.
getparams
and setparams!!
following AbstractMCMC v5.5getparams
and setparams!!
following AbstractMCMC v5.5 and v5.6
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
95cba2b
to
30dca23
Compare
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.
Good stuff @sunxd3 :)
ref: TuringLang/Turing.jl#2367