commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MATH-404) Confusing interface for "LevenbergMarquardtOptimizer"
Date Tue, 10 Aug 2010 11:38:19 GMT

    [ https://issues.apache.org/jira/browse/MATH-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896859#action_12896859
] 

Gilles commented on MATH-404:
-----------------------------

Sorry I hadn't followed that other report.

{quote}
It was decided to let both convergence methods available. 
{quote}

Switching between two convergence checking procedures, based on whether a field is {{null}}
or not, is at best a temporary workaround, but it is not a good solution.

As explained above, from an OOP point-of-view, it is surprising that a class completely circumvents
its base class interface.
At least one of the following is wrong:
* {{LevenbergMarquardtOptimizer}} inherits from {{AbstractLeastSquaresOptimizer}}
* {{LevenbergMarquardtOptimizer}} has a second interface for convergence checking
*  {{AbstractLeastSquaresOptimizer}} defines the interface for  convergence checking

{quote}
[...] does not fit with the general scheme.
{quote}

Then maybe the scheme needs to be reviewed so that it is general enough to fit.
Allow me to remind what you said: convergence checking is independent from the optimization
algorithm.
But then, in the LM implementation, this doesn't hold...

If it is really impossible to fit LM within the hierarchy it currently belongs to, then it
should not belong to it, since one cannot leverage the advantages of "interface programming"
anyways.


> Confusing interface for "LevenbergMarquardtOptimizer"
> -----------------------------------------------------
>
>                 Key: MATH-404
>                 URL: https://issues.apache.org/jira/browse/MATH-404
>             Project: Commons Math
>          Issue Type: Bug
>    Affects Versions: 2.1
>            Reporter: Gilles
>             Fix For: 2.2
>
>
> {{LevenbergMarquardtOptimizer}} inherits from {{AbstractLeastSquaresOptimizer}} which
in turn implements {{DifferentiableMultivariateVectorialOptimizer}}. That interface mandates
methods for setting and getting a {{VectorialConvergenceChecker}}.
> In v2.1, however, that checker is never used! The convergence check is performed using
parameters specific to the Levenberg-Marquardt algorithm. Such circumvention of the superclass
interface is confusing and leads to totally unexpected behaviour (such as changing the values
of the thresholds of the {{VectorialConvergenceChecker}} being ineffective).
> In the development version, the default constructor of {{LevenbergMarquardtOptimizer}}
sets the the {{VectorialConvergenceChecker}} field to "null" and when such is the case, the
behaviour is as in v2.1. Although it is documented, this is still confusing since it is impossible
to use {{LevenbergMarquardtOptimizer}} through its {{DifferentiableMultivariateVectorialOptimizer}}
interface: When using the {{VectorialConvergenceChecker}}, one does not know what parameters
to use in order to reproduce the results obtained with the LM-specific convergence check (i.e.
how to reproduce the result from v2.1).
> Unless I'm missing something, I think that there should be an LM-specific implementation
of {{VectorialConvergenceChecker}} that, when given the usual relative and absolute thresholds,
can perform a check that will give the same result as the currently specific check (when the
"checker" field is "null").

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message