Bringback old getparams

[JaimeRZP]

getparams(t) = t.θ is extremely useful to connect external samplers to Turing while

# NOTE: Only thing that depends on the underlying sampler.
# Something similar should be part of AbstractMCMC at some point:
# https://github.com/TuringLang/AbstractMCMC.jl/pull/86
getparams(transition::AdvancedHMC.Transition) = transition.z.θ
getstats(transition::AdvancedHMC.Transition) = transition.stat

getparams(transition::AdvancedMH.Transition) = transition.params

getvarinfo(f::DynamicPPL.LogDensityFunction) = f.varinfo
getvarinfo(f::LogDensityProblemsAD.ADGradientWrapper) = getvarinfo(parent(f))

setvarinfo(f::DynamicPPL.LogDensityFunction, varinfo) = Setfield.@set f.varinfo = varinfo
setvarinfo(f::LogDensityProblemsAD.ADGradientWrapper, varinfo) = setvarinfo(parent(f), varinfo)

get properly pushed into abstractmcmc.

[JaimeRZP]

@torfjelde Could you quickly have a look? It is just one line of code that I need to connect some external samplers to Turing.

[devmotion]

Maybe it would be better to finish TuringLang/AbstractMCMC.jl#86?

[codecov]

Codecov Report

Patch and project coverage have no change.

Comparison is base (8d8416a) 0.00% compared to head (5734dca) 0.00%.

Additional details and impacted files

@@          Coverage Diff           @@
##           master   #2086   +/-   ##
======================================
  Coverage    0.00%   0.00%           
======================================
  Files          21      21           
  Lines        1451    1452    +1     
======================================
- Misses       1451    1452    +1     

Files Changed	Coverage Δ
src/mcmc/Inference.jl	0.00% <0.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JaimeRZP]

Maybe it would be better to finish TuringLang/AbstractMCMC.jl#86?

I completely agree that this is ultimately the correct solution.
This is just an extremely quick patch to allow external libraries to connect to Turing.
The latest change broke a lot of connections, this brings back that functionality while we work on the proper solution.

[torfjelde]

Am away from computer atm; will have a look when I get back.

…

On Sat, Sep 23, 2023, 11:53 AM Jaime RZ ***@***.***> wrote: Maybe it would be better to finish TuringLang/AbstractMCMC.jl#86 <TuringLang/AbstractMCMC.jl#86>? I completely agree that this is ultimately the correct solution. This is just an extremely quick patch to allow external libraries to connect to Turing. The latest change broke a lot of connections, this brings back that functionality while we work on the proper solution. — Reply to this email directly, view it on GitHub <#2086 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPZZFM45TXGYPOFFYPEADX325TTANCNFSM6AAAAAA5DHHO5E> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[torfjelde]

Sorry, why can't we just provide the model and use the existing getparams?

[torfjelde]

And I'm also very much in favor of what @devmotion is suggesting

[JaimeRZP]

Sorry, why can't we just provide the model and use the existing getparams?

Because that's not the signature of getparams used in TuringTransition. See code here

[torfjelde]

Sure, but there's nothing stopping us from just changing TuringTransition to use this signature, right? It would just be mapping getparams(transition) to getparams(f.model, transition) (and this should of course have been done in the PR that original introduced this new getparams)

[JaimeRZP]

Sure.
We can now close this PR in favour yours!