Skip to content

Boundary updates #434

Open
Open
@segasai

Description

In #428 I've refactored the boundary update rules, but it's not 100% clear if everything there is optimal.

First, the boundary updates is something that's mildly important for non-uniform sampling, but critically important for uniform sampling.

Right now the boundary is updated (

def update_bound_if_needed(self, loglstar, ncall=None, force=False):
)

  • at the beginning of the run when ncall is larger than some threshold, and efficiency becomes lower than a threshold
  • During the run if a threshold ncall since the previous boundary update has passed

Also the bound update is relevant when starting a new batch. There, a new sampler is created and it the bound is
either used from a base run, or the run will start without the bound if logl< logl_first_bound_update. That's where things can be potentially inefficient as in the latter case the whole nlive set of pts has to be generated from unit cube.

Also it is still not clear to me if

  • The boundary update need to be delayed like it is now. I previously remember the discussion about shredding of the posterior, but I don't quite know if that's a real problem and if delaying the bound creation is useful for that.

  • I don't particularly like that things are decided based on 'efficiency' which is a cumulative efficiency. It is unclear if the cumulative efficiency is ever useful. I'd say efficiency over last nlive samples probably is.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions