From issues-return-14928-apmail-commons-issues-archive=commons.apache.org@commons.apache.org Wed Sep 01 12:45:41 2010 Return-Path: Delivered-To: apmail-commons-issues-archive@minotaur.apache.org Received: (qmail 72448 invoked from network); 1 Sep 2010 12:45:40 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Sep 2010 12:45:40 -0000 Received: (qmail 73242 invoked by uid 500); 1 Sep 2010 12:45:38 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 72271 invoked by uid 500); 1 Sep 2010 12:45:35 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 72263 invoked by uid 99); 1 Sep 2010 12:45:34 -0000 Received: from Unknown (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Sep 2010 12:45:34 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Sep 2010 12:45:16 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o81Cisqq010073 for ; Wed, 1 Sep 2010 12:44:54 GMT Message-ID: <27454216.114561283345094483.JavaMail.jira@thor> Date: Wed, 1 Sep 2010 08:44:54 -0400 (EDT) From: "Gilles (JIRA)" To: issues@commons.apache.org Subject: [jira] Commented: (MATH-413) Miscellaneous issues concerning the "optimization" package In-Reply-To: <5319585.68761283174395078.JavaMail.jira@thor> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/MATH-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12905010#action_12905010 ] Gilles commented on MATH-413: ----------------------------- The main problem is not whether it is deemed complicated or not to initialize the checker. The fact is that the convergence checker procedure is _not_ (always) independent of the algorithm (as in the cases of {{BrentOptimizer}} and {{LevenbergMarquardtOptimizer}}). Currently it is very dangerous to assume that convergence check is independent and will always work correctly. This severely impacts the robustness of CM; thus it is a big problem, and it seems that the current approach cannot solve it. * As I have suggested, we could try to _modify_ the algorithms in such a way that an independent checking procedure is always valid. The drawback is that we'll have non-standard behaviour of otherwise well-known algorithms and some users won't like it (cf. request by the reporter of issue [MATH-362|https://issues.apache.org/jira/browse/MATH-362]). * An alternative is to go back to a "simple", algorithm-specific convergence check (i.e. what most users are already used to), with tolerances parameters passed through the constructor. * To enhance the checking (in effect, trying to recover the flexibility of {{ConvergenceChecker}} functionality), I'd propose to optionally enable a "callback" to be called after each iteration with two arguments (the previous and current best point/value pairs) and that should return "SUCCESS" (an {{enum}}) if the current best point is good enough and "CONTINUE" if it is not. It is indeed very much like the existing {{converged}} method but the main idea is that the default convergence check (the one tied with the optimization algorithm) will always have a higher priority: if it passes, we exit from the iteration loop. The callback is a _second_ check that gives the opportunity to exit earlier if some additional, user-defined, criteria are met. Combining the last two points, we # always provide a self-consistent behaviour in the simple use-cases # make it clear that the user can optionally define an "out-of-band" checking criterion: it is clearly independent in that any parameter (apart from the previous and current points) used to check convergence must be separately collected and passed to the constructor of the callback. What do you think? > Miscellaneous issues concerning the "optimization" package > ---------------------------------------------------------- > > Key: MATH-413 > URL: https://issues.apache.org/jira/browse/MATH-413 > Project: Commons Math > Issue Type: Bug > Reporter: Gilles > Fix For: 3.0 > > > Revision 990792 contains changes triggered the following issues: > * [MATH-394|https://issues.apache.org/jira/browse/MATH-394] > * [MATH-397|https://issues.apache.org/jira/browse/MATH-397] > * [MATH-404|https://issues.apache.org/jira/browse/MATH-404] > This issue collects the currently still unsatisfactory code (not necessarily sorted in order of annoyance): > # "BrentOptimizer": a specific convergence checker must be used. "LevenbergMarquardtOptimizer" also has specific convergence checks. > # Trying to make convergence checking independent of the optimization algorithm creates problems (conceptual and practical): > ** See "BrentOptimizer" and "LevenbergMarquardtOptimizer", the algorithm passes "points" to the convergence checker, but the actual meaning of the points can very well be different in the caller (optimization algorithm) and the callee (convergence checker). > ** In "PowellOptimizer" the line search ("BrentOptimizer") tolerances depend on the tolerances within the main algorithm. Since tolerances come with "ConvergenceChecker" and so can be changed at any time, it is awkward to adapt the values within the line search optimizer without exposing its internals ("BrentOptimizer" field) to the enclosing class ("PowellOptimizer"). > # Given the numerous changes, some Javadoc comments might be out-of-sync, although I did try to update them all. > # Class "DirectSearchOptimizer" (in package "optimization.direct") inherits from class "AbstractScalarOptimizer" (in package "optimization.general"). > # Some interfaces are defined in package "optimization" but their base implementations (abstract class that contain the boiler-plate code) are in package "optimization.general" (e.g. "DifferentiableMultivariateVectorialOptimizer" and "BaseAbstractVectorialOptimizer"). > # No check is performed to ensure the the convergence checker has been set (see e.g. "BrentOptimizer" and "PowellOptimizer"); if it hasn't there will be a NPE. The alternative is to initialize a default checker that will never be used in case the user had intended to explicitly sets the checker. > # "NonLinearConjugateGradientOptimizer": Ugly workaround for the checked "ConvergenceException". > # Everywhere, we trail the checked "FunctionEvaluationException" although it is never used. > # There remains some duplicate code (such as the "multi-start loop" in the various "MultiStart..." implementations). > # The "ConvergenceChecker" interface is very general (the "converged" method can take any number of "...PointValuePair"). However there remains a "semantic" problem: One cannot be sure that the list of points means the same thing for the caller of "converged" and within the implementation of the "ConvergenceChecker" that was independently set. > # It is not clear whether it is wise to aggregate the counter of gradient evaluations to the function evaluation counter. In "LevenbergMarquartdOptimizer" for example, it would be unfair to do so. Currently I had to remove all tests referring to gradient and Jacobian evaluations. > # In "AbstractLeastSquaresOptimizer" and "LevenbergMarquardtOptimizer", occurences of "OptimizationException" were replaced by the unchecked "ConvergenceException" but in some cases it might not be the most appropriate one. > # "MultiStartUnivariateRealOptimizer": in the other classes ("MultiStartMultivariate...") similar to this one, the randomization is on the firts-guess value while in this class, it is on the search interval. I think that here also we should randomly choose the start value (within the user-selected interval). > # The Javadoc utility raises warnings (see output of "mvn site") which I couldn't figure out how to correct. > # Some previously existing classes and interfaces have become no more than a specialisation of new "generics" classes; it might be interesting to remove them in order to reduce the number of classes and thus limit the potential for confusion. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.