Proposals:Refactoring of optimization framework

From KitwarePublic
Jump to navigationJump to search

Refactor Optimization Framework Based on Available Function Derivative Information

The proposed changes attempt to be backwards compatible with the current optimization framework.

Modification to cost function hierarchy

Currently all cost functions are subclasses of itk::SingleValuedCostFunction or itk::MultipleValuedCostFunction. These two classes are pure virtual, forcing the user to implement a GetDerivative() method. This assumes that the optimized function is differentiable. When this is not the case, developers either provide a bogus derivative which is problematic if they unintentionally use an optimizer that utilizes this information, otherwise they often throw an exception. The current and proposed hierarchies are given below (these are not valid UML diagrams).

Current hierarchy:
CurrentOptimizedFunctionHeirarchy.svg


Proposed hierarchy:
ProposedOptimizedFunctionHeirarchy.svg


The methods GetDerivative() and GetValueAndDerivative() move from the SingleValuedCostFunction to the newly created SingleValuedCostFunctionWithDerivative. In addition we have a decorator class SingleValuedCostFunctionWithFiniteDiffernceDerivative which wraps a user supplied SingleValuedCostFunction.

Modification to optimizer hierarchy

Reflects the hierarchy of cost functions. Add a direct subclass itk::SingleValuedWithDerivativeNonLinearOptimzer to itk::SingleValuedNonLinearOptimzer. Optimizers that use derivatives are decedents of this class, otherwise decedents of the SingleValuedNonLinearOptimzer. This is not straightforward, some classes in the current hierarchy are superclasses of both types of optimization methods (e.g. itk::SingleValuedNonLinearVnlOptimizer is the parent of itk::AmoebaOptimizer and itk::ConjugateGradientOptimizer).