Allow user to define a schedule for adaptation during burn-in #79

Activity

1. sam0287

   added

   enhancementNew feature or requestNew feature or request

   on Jul 16, 2025
2. matt-graham commented on Jul 17, 2025

   

   matt-graham

   on Jul 17, 2025

   Collaborator

   More actions

   Hi @LkHardcastle, thanks for raising this!

   Extending the adaptation interface to support this sort of scheduling / staging is definitely a good idea, and I like your proposed interface of just having the adapters argument to sample_chain accept a list of per-stage adapters and number of iterations.

   In addition to the above, is it possible for the user to fix either the scale or shape of the proposal but learn the other adaptively?

   Yes, rmcmc already allows either just the proposal shape or scale to be adapted, by just passing in a single adapter in the list passed to sample_chains, for example adapters = list(scale_adapter()) would just adapt the scale (in which case the shape is implicitly assumed to be an identity matrix). I think because of this we can probably get away without needing to have an explicit fixed_shape dummy adapter object so in your example above could just have list(scale_adapter(), 50) as the first stage specification.

   In Mici, something similar is implemented by the mici.stagers module, which creates a object which returns a sequence of 'chain stages', each defining the adapters to be used and number of iterations in the stage. These objects automatically alllocate the number of iterations per stage based on the number of warm-up iterations. I like the simpler interface of your proposal, but I think we could also support something similar for common schedule configurations by allowing also passing a function to the adapters argument that will be called with n_warm_up_iteration as the argument, to allow quickly setting up standard schedules that will work whatever the number of warm-up iterations the user specifies. For example if we had something like this with

   progressive_adaptation_schedule <- function(
       n_fixed_shape_iteration = 50,
       n_diagonal_shape_iteration = 50,
       scale_adapter_ = scale_adapter(),
       diagonal_shape_adapter = shape_adapter("variance"),
       dense_shape_adapter = shape_adapter("covariance"),
   ) {
       function(n_iteration) {
           if (n_fixed_shape_iteration + n_diagonal_shape_iteration) > n_iteration) {
               n_fixed_shape_iteration <- n_iteration %/% 2
               n_diagonal_shape_iteration <- n_iteration - n_fixed_shape_iteration
           }
           n_dense_shape_iteration <- max(n_iteration - n_fixed_shape_iteration - n_diagonal_shape_iteration, 0)
           list(
               list(scale_adapter_, n_fixed_shape_iteration),
               list(scale_adapter_, diagonal_shape_adapter , n_diagonal_shape_iteration),
               list(scale_adapter_, dense_shape_adapter, n_dense_shape_iteration)
           )
       }
   }

   then your example above could be

   results <- sample_chain(..., adapters = progressive_adaptation_schedule())

   while still allowing the user the flexibility to fully customise the scheduling by directly passing in a list (or doing variants of the above scheme by altering the default arguments to progressive_adaptation_schedule).
3. jennajiali

   added a commit that references this issue on Jun 25, 2026

   Fix adapter state carry-over between staged warm-up stages and add in…

   ...

   6e246d9
4. matt-graham

   linked a pull request that will close this issueImplement staged warm-up adaptation schedule #127on Jul 16, 2026
5. matt-graham

   added a commit that references this issue on Jul 22, 2026

   Implement staged warm-up adaptation schedule (#127)

   ...

   f399737
6. matt-graham

   closed this as completedin #127on Jul 22, 2026