Change Optimiser/MCMC objects to work with 'ask-and-tell' interface

[MichaelClerx]

In that case, users could do something like this:

mcmc = ...
while True:
    result = mcmc.iterate()
    if result.is_finished():
        break
    if every 100th iteration:
        store to disk
    if every 10th iteration
        print diagnostics, current state etc.

This would allow users to set up arbitrarily complex search routines, including logging final results to disk, storing partial results on disk, stopping/restarting, showing as much output data as they like in whatever form they like, storing output data somewhere on a server in a way that websites or other clients can read it etc.

[MichaelClerx]

Copied from #185:

I strongly believe all our methods should work like this:

• We set up some object (MCMC class, Optimiser class)
• We set up a loop, from wherein
  • we call an iterate() method, this advances us one step and then asks us to evaluate the model on some new points
  • we do logging, debug output, talk to calling processes, check stopping criteria
  • we evaluate the model (possibly parallelised on a CPU/GPU) and pass back the information

This would then have to be integrated with the result objects (#129 for MCMC/inference, #137 for optimisation)

[MichaelClerx]

Example for an optimiser:

# Create optimiser object (with fresh internal state)
opt = AReallyGoodOptimiser(boundaries, x0, sigma0)

# Configure (this could be extensive)
opt.set_setting1(0.5)
opt.set_setting2(novell_heuristic(1,2,3))
...

# Configure stopping criteria
absolute_tolerance = 1e-6
max_iterations_without_change = 50
no_change_cutoff = 1e-12

# Run optimisation
halt = False
while not halt:
    # Ask for point or points to evaluate
    x = opt.ask()
    
    # Evaluate points
    # This could be (GPU) parallelised
    fx = evaluate(x)
    
    # Perform the next iteration
    # This updates the optimiser's internal state
    opt.tell(x, fx)
    
    # Perform logging, debug output etc.
    print(x, fx)
    print(opt._some_internal_parameter_i_am_studying)
    file.write(x, fx, ...)
    network.send(x, fx, ...)
    progress_bar.update()
    
    # Check stopping criteria
    halt = halt or (criteria1)
    halt = halt or (criteria2)
    halt = halt or (criteria3)
    ...

# Run a second optimisation
# This resets the optimisers state, but doesn't affect the settings
opt.reset(boundaries, x0, sigma0)

# Run optimisation
...

This would be the "hard" interface, intended for people who want to use pints as a library inside some other project, who want to do some testing/debugging/benchmarking, etc.

We would then write a simpler method you would use like this:

pints.minimise(pints.CMAES, function, boundaries, x0, sigma0)

or even

pints.minimise(pints.CMAES, function, boundaries, x0, sigma0, very_important_param1, very_important_param2)

as long as we keep the number of very important parameters to an absolute minimum (I want to avoid the hideously long parameter lists you see e.g. in numpy's optimiser calls, or the difficult-to-document settings dictionaries in e.g. pycma)

Thoughts? @martinjrobins @ben18785 ? Would inference routines fit in a similar scheme?

[MichaelClerx]

It would also allow us to write cool wrapper functions e.g.

p = pints.optimise_and_plot(pints.PSO, function, ...)

which could create plots of the particles travelling through (a low-dimensional representation of) the search space, and update them at each iteration

or things like a routine that stores in some particular format we like, or ones that send progress reports over a network, etc.

[martinjrobins]

Yup, love the flexibility of this. It would really help with the hierarchical sampling I'm doing. As long as this inteface would work with all the inference algorithms I'm for it.

[ben18785]

Sorry, being slow, what does "ask and tell" mean? Is the idea to have two interfaces: one that is uncustomisable that runs samplers etc. in a default manner, and another which can be much more easily customised/embedded in a larger project? If so, think it's a good idea!

…

On Thu, Jan 18, 2018 at 10:43 AM, Martin Robinson ***@***.***> wrote: Yup, love the flexibility of this. It would really help with the hierarchical sampling I'm doing. As long as this inteface would work with all the inference algorithms I'm for it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#132 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AESFqHlRnhkb7H-PWYHUduWpg0IMZO8iks5tLyBHgaJpZM4Q35N2> .

[MichaelClerx]

Sorry, being slow, what does "ask and tell" mean?

It means that the optimiser stops after every iteration to ask you for the evaluation of your function (or logposterior) at selected points, and continues when you tell it.
CMA-ES uses it, for example, and some googling showed me scikit uses it too: https://scikit-optimize.github.io/notebooks/ask-and-tell.html

Is the idea to have two interfaces: one that is uncustomisable that runs samplers etc. in a default manner, and another which can be much more easily customised/embedded in a larger project? If so, think it's a good idea!

Yes!