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.

The UML like diagrams on this page were created with DIA. The source files for these are available here.

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.

Current hierarchy:
CurrentOptimizerHeirarchy.svg

Proposed hierarchy:
Optimizers that do not use derivatives: ProposedOptimizerHeirarchyPart1.svg

Optimizers that use derivatives:
ProposedOptimizerHeirarchyPart2.svg