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 15:41:19 GMT

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

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

{quote}
What would you propose for this ?
{quote}

I don't know.

However, it seems that this "non-fitting checker" case is not isolated. I wanted to replace
the original check in "BrentOptimizer" (package "optimization.univariate") by a call to an
appropriate subclass of "RealConvergenceChecker", but here too there are more values to be
considered than those stored in a pair of "RealPointValuePair". The check needs
* the "current" point
* the points at both interval ends

but it does not use the "previous" point.

So it seems that this also does not fit with the "converged" method of the "RealConvergenceChecker"
interface.

At first sight, I'd say that there should be a more general "ConvergenceChecker" (not existing
yet) interface. Maybe using generics...


> 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