TuringLang / AbstractMCMC.jl

Abstract types and interfaces for Markov chain Monte Carlo methods
https://turinglang.org/AbstractMCMC.jl
MIT License
78 stars 18 forks source link

Allow specification of initial state for `sample` #119

Closed torfjelde closed 10 months ago

torfjelde commented 1 year ago

This seems convenient to have, e.g. for resuming sampling, running special warm-up procedures.

EDIT: Note that this is now dependent on #126

codecov[bot] commented 1 year ago

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (4dbcb3f) 97.37% compared to head (3ed5314) 96.87%. Report is 4 commits behind head on master.

Additional details and impacted files ```diff @@ Coverage Diff @@ ## master #119 +/- ## ========================================== - Coverage 97.37% 96.87% -0.51% ========================================== Files 8 8 Lines 305 320 +15 ========================================== + Hits 297 310 +13 - Misses 8 10 +2 ``` | [Files](https://app.codecov.io/gh/TuringLang/AbstractMCMC.jl/pull/119?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=TuringLang) | Coverage Δ | | |---|---|---| | [src/AbstractMCMC.jl](https://app.codecov.io/gh/TuringLang/AbstractMCMC.jl/pull/119?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=TuringLang#diff-c3JjL0Fic3RyYWN0TUNNQy5qbA==) | `100.00% <ø> (ø)` | | | [src/sample.jl](https://app.codecov.io/gh/TuringLang/AbstractMCMC.jl/pull/119?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=TuringLang#diff-c3JjL3NhbXBsZS5qbA==) | `95.87% <93.10%> (-0.78%)` | :arrow_down: |

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

torfjelde commented 1 year ago

Can you add tests of all new lines?

Will do (but tomorrow; am about to sleep)!

The names init_params and initial_state seem inconsistent, can we either use init or initial in both cases?

Agreed. Hmm, I guess I'll make it init_state then? Personally prefer the initial_* but given that one already exists, I guess it makes sense to add this (though this init_params isn't even offiically supported, right?)

devmotion commented 1 year ago

though this init_params isn't even offiically supported, right?

It's officially supported: It's clearly documented and used in downstream packages such as EllipticalSliceSampling, DynamicPPL, and Turing.

torfjelde commented 1 year ago

It's officially supported: It's clearly documented and used in downstream packages such as EllipticalSliceSampling, DynamicPPL, and Turing.

Yes, that I'm fully aware of! Just remembered seeing the following in the docs:

There is no "official" way for providing initial parameter values yet. However, multiple packages such as EllipticalSliceSampling.jl and AdvancedMH.jl support an init_params keyword argument for setting the initial values when sampling a single chain. To ensure that sampling multiple chains "just works" when sampling of a single chain is implemented, we decided to support init_params in the default implementations of the ensemble methods:

Which I took to mean "we haven't really made an explicit decision on how to support initial parameters, but because so many downstream packages use init_params, we stay compatible with it".

But nonetheless, I'll change it to init_state then :+1:

devmotion commented 1 year ago

Generally, I think I'd prefer initial but yeah, it involves more changes :shrug: I'm also not a big fan of the name params, maybe initial_sample would be better?

Since #120 requires a breaking release anyway, we could also include more breaking changes. Otherwise we could deprecate the keyword argument, maybe something like the following could work:

function f(...; init_params=nothing, initial_params=init_params)
    if init_params !== nothing
        if initial_params !== init_params
            throw(ArgumentError("..."))
        end
        Base.deprecate("....", f)
    end
    ...
end
torfjelde commented 11 months ago

@devmotion I just came across this again; given that we decided to scrap #120 in the end, what do you think of at least merging this? Being able to specify the initial state would be quite useful.

EDIT: Just remember you're on vacation! No need to rush this:)

torfjelde commented 10 months ago

I decided to just rip the band-aid off and go with renaming init_params to initial_params right away.

If we don't, we end up in a somewhat awkward scenario where we have to pass along both init_params and initial_params, which might also just break downstream step.

devmotion commented 10 months ago

Can we merge #126 first and then rebase this PR on it? Or maybe even directly rebase the PR on #126 and adjust the base branch of the PR?

torfjelde commented 10 months ago

Most certainly :+1:

torfjelde commented 10 months ago

Rebased and change base for PR.

I'll add some tests for the intial_state stuff sometime today :+1:

devmotion commented 10 months ago

Seems the PR breaks EllipticalSliceSampling? 🤔 Interesting, even though it won't cause any breakage in practice if we tag a breaking release.

torfjelde commented 10 months ago

Could it maybe be something related to init_params -> initial_params?

But yes, I'll bump the major version so won't break anything in practice:)

devmotion commented 10 months ago

Yeah, I assume that's the reason: https://github.com/TuringLang/EllipticalSliceSampling.jl/blob/ca4babb2baba9008805bc8234a6fd182119e57dc/src/abstractmcmc.jl#L25 https://github.com/TuringLang/EllipticalSliceSampling.jl/blob/ca4babb2baba9008805bc8234a6fd182119e57dc/test/simple.jl#L40 I wonder though why other packages that currently use init_params (AdvancedMH IIRC? Turing?) are not affected by this change. Maybe they are missing tests for init_params/initial_params?

torfjelde commented 10 months ago

Maybe they are missing tests for init_params/initial_params?

Very likely :confused: