Compose managers/states

[sglyon]

I would like to be able to compose managers and states.

This would enable us to write high quality code for specific purposes in individual managers and "opt-in" to functionality through composition.

[tbreloff]

To expand on this, it would be great to have small, lightweight managers (middle management) that do one thing. And a "CEO" that controls the whole iteration loop. The middle mgmt would do things like early stopping checks, traces, plotting, etc. The CEO would have a list of sub managers and each submanager would be envoked on each step. Internally we could split into several vectors, one for each "hook", so that an early stopping check isn't called for post-loop processing.

Building a new iteration manager (CEO) would entail passing a list of the middle management that you'd like to be active. And I hope we can dynamically turn them on/off between iterations if needed. We can likely provide some nice defaults and convenience methods for simple construction in the common cases.

Any new thoughts since you started this issue?

[tbreloff]

cc @Evizero @joshday @ahwillia @pkofod

[tbreloff]

It might make sense to define additional hooks for middle management. For example, plot_hook, trace_hook, etc. The reason is that the developer of a solver may wish to do very specific things for plotting or tracing or early stopping, but that it is messy to put all that logic in one place, especially when we want dynamic and composable managers. This way you can keep everything separate and modular and avoid the plague of if dotrace; trace(); end; if doplot; plot(); end ...

[Evizero]

I don't think I know enough about the inner workings to give an informed opinion. My general recommendation is to give the user as much control as possible if he wants it

[tbreloff]

Another quick thought... maybe there should be one "CEO" that composes both managers and states. For example, if we have a sub-manager that is in charge of checking max iterations, then it should be coupled with a state that knows the current iteration number. Do the sub-managers retain state, or do we need to "match" a manager to the appropriate state? I want to avoid putting the same fields in every manager/state, and that might mean blurring the line between the two (a state may have manager-like fields, or vice versa)

For example, this manager requires that it is matched with a state that implements num_iter:

finished(mgr::IterManager, istate::IterationState) =
    num_iter(istate) > mgr.maxiter

If we had composable states, there could be:

type IterState; n::Int; end
num_iter(istate::IterState) = istate.n

Then the CEO's job would be to "match up" the IterManager with the IterState when making the call to finished. We could do this through some sort of traits mechanism, or even just by checking for method existence during CEO construction?

This way the CEO would make callbacks in pairs:

function finished(ceo::CEO)
    fin = false
    for (mgr,state) in ceo.finished_callbacks
        fin = fin || finished(mgr, state)
    end
    fin
end

[sglyon]

Thanks for leaving the comments here -- these are definitely good ideas that we should give thought to and have discussion about. I am traveling and won't have time give a thought out response for a few days -- I just wanted to pop in here to let you know I've seen the messages and am thinking about them!

[pkofod]

Also popping in to say that I am following. I agree with Christof that flexibility is key. If it can't be bent and twisted to the users need, people will just end up doing their own version anyway. I will have to look at the actual functionality in here to come with a better comment though.