Checkpointing

[michaeldeistler]

Checkpointing and new API for multi-round

API

# Run additional rounds with the last posterior as new proposal.
proposal = None
posteriors = []
for round_ in range(num_rounds):
    posterior = infer(num_simulations=200, proposal=proposal)
    proposal = posterior.set_default_x(x_o)
    posteriors.append(posterior)

Main changes

• no more x_o argument
• no more _x_o_trained_on attribute
• proposal needs to be passed as a function only in theta

[michaeldeistler]

Hi @jan-matthis @janfb @Meteore

for my STG project, I need the mechanism described above, so I would like to implement it in sbi soon. Please let me know if you have a preference for suggestion 1 or suggestion 2.

To seed this discussion:
I prefer suggestion 1 because:
a) it does not require an additional argument to __call__()
b) having a .continue() function makes it very explicit to the user what is happing.

[alvorithm]

Hi @jan-matthis @janfb @Meteore

for my STG project, I need the mechanism described above, so I would like to implement it in sbi soon. Please let me know if you have a preference for suggestion 1 or suggestion 2.

To seed this discussion:
I prefer suggestion 1 because:
a) it does not require an additional argument to __call__()
b) having a .continue() function makes it very explicit to the user what is happing.

I would like us to list somewhere the state that we are carrying around and cannot be managed as return values that get passed again into one round of inference. I mentioned something similar on the PR about external data and I think it is a discussion worth to have, possibly in a dedicated meeting.

PS. not sure I understand what start_new_round is doing and how it interacts with num_rounds.

[michaeldeistler]

Here's a list of the state:

• _theta_roundwise
• _x_roundwise
• _prior_masks
• _data_round_index
• _posterior
• _model_bank

[michaeldeistler]

In the example above, start_new_round=False and hence the next simulations will still come from the same distribution as in the round before, in this case from the prior. If it were True, we would start a new round, i.e. a second round and hence simulate from the posterior.

num_rounds simply indicates how many rounds are being run in the current call to __call__() or .continue(), respectively.

[michaeldeistler]

@jan-matthis @janfb @Meteore After quite some discussions yesterday, we thought that it might be a good idea to change the API of multi-round. In the description of this PR, I outline one way to do it. Have a look and let me know what you think.

The code for this is also "ready" (despite only for snpe and not documented yet), so, if you want, also have a look at that.

[jan-matthis]

Had a first look at the PR, looking good! I guess SNLE, SNRE, tests and changes to infer() are still forthcoming

[jan-matthis]

I'm seeing no invocation of this method in the code, shouldn't it be called at some point?

[michaeldeistler]

The user has to call it after inference. See the API example in the PR description.

[jan-matthis]

Ah, I see. I missed the edited version. How about sticking to method names that unspecific to training/inference?

[jan-matthis]

For example:

# Single round inference with prior as proposal
posterior = infer(num_simulations=200, proposal=None)   # proposal=None is also default.
posteriors = [posterior]

# Run additional rounds with the last posterior as new proposal.
for round_ in range(1, num_rounds):
    posteriors.append(infer(num_simulations=200, proposal=posteriors[round_-1].set_default_x(x_o)))

[jan-matthis]

Or shorter:

posteriors = []
proposal = None
for _ in range(num_rounds):
    posterior = infer(num_simulations=200, proposal=proposal)
    proposal = posterior.set_default_x(x_o)
    posteriors.append(posterior)

[jan-matthis]

More generally, I wonder if infer() should keep a num_rounds keyword and build such a loop internally