A priority for future development should be to make this package compatible with arbitrary derivative-free Optim.jl or BlackBoxOptim.jl optimization algorithms. These problems are formulated not as Bayesian inverse problems but purely in terms of the objective function that needs to be minimized. However, I think we should still use the InverseProblem, OutputMap and Tranformation constructs to set up the problem and compute the objective; there will just be the open question of what kinds of options to provide for what form the objective function should take (e.g. regularized or unregularized).
Before I implement an API, does anyone have strong opinions about what kind of flexibility should be available? For now, I think a keyword argument regularized indicating which version of the EKI objective is desired might be all we need.
A priority for future development should be to make this package compatible with arbitrary derivative-free
Optim.jlorBlackBoxOptim.jloptimization algorithms. These problems are formulated not as Bayesian inverse problems but purely in terms of the objective function that needs to be minimized. However, I think we should still use theInverseProblem,OutputMapandTranformationconstructs to set up the problem and compute the objective; there will just be the open question of what kinds of options to provide for what form the objective function should take (e.g. regularized or unregularized).Before I implement an API, does anyone have strong opinions about what kind of flexibility should be available? For now, I think a keyword argument
regularizedindicating which version of the EKI objective is desired might be all we need.