I see that BOBYQAOptimizer calls getEvaluations(). The too many evaluations exception can be caught on the doOptimizations level, and the currentBest value can be extracted.
I would like to stress my original point. In an expensive optimization it is not clear a priori if you always have the time or the ability to converge to the optimal value. However, it is important that the best current value be returned anyways, since its better than what you started with. If you are unable to provide the functionality through the convergence checker, please just add this into the thrown exception, as original discussed. We can figure out how to do it cleaner later. BOBYQAOptimizer is used for expensive optimizations, such a functionality is critical. In my opinion the exception hack is easier to implement and would allow consistency for all optimization methods. On Dec 18, 2012, at 1:58 PM, Gilles Sadowski <gil...@harfang.homelinux.org> wrote: > On Tue, Dec 18, 2012 at 01:24:06PM -0500, Konstantin Berlin wrote: >> -1 >> >> Per issue MATH-902: >> >> Its hard for me to read all the code, but at first pass it seems that in >> BOBYQAOptimizer, maybe for others, no convergence criterion is set. So there >> is actually no way to set the maximum number of iterations. > > You are quite right but, as far as I'm concerned, BOBYQA is unsupported: > https://issues.apache.org/jira/browse/MATH-621 > > Currently, the code behaves as the initial port from FORTRAN. > Before adding new behaviours, it must be thoroughly cleaned up, while still > passing all the tests, or knowing why it doesn't. This is not an easy task, > as mentioned in some of the above issue's comments. > > [Speaking of "time": I've already spent several tens of hours to make this > code more readable. It's far from done, and as much was already mentioned > in the 3.0 release notes. > Until this code is refactored to meet the minimum of maintainability that is > expected (by me, at least) from Commons Math, I have no inclination to put > more work on it on my own.] > >> On that note. The optimization data is parsed at runtime, which is bad >> because it leads to error prone code, since the user cannot tell that he is >> passing an option that is ignored (or incorrect) until that line is actually >> executed during runtime. In addition, if he is passing multiple options of >> the same base class, something that is hard to notice unless you go down the >> hierarchy tree for all your input classes, only the last option is actually >> set, without any exception or warning given to the user. > > I also noticed this drawback of the new API; however it must be balanced > with the advantages (which were also presented in an earlier post, and show > in the obvious code simplifications). > > As I told you, that's most probably not the end of the story, but we are > certainly better off with the new API as a starting point for further > improvement. > Please provide an alternative design. > > > Regards, > Gilles > > >> On Dec 18, 2012, at 12:49 PM, Gilles Sadowski <gil...@harfang.homelinux.org> >> wrote: >> >>> Hi. >>> >>> Method "getCovariances()" in >>> org.apache.commons.math3.optimization.general.AbstractLeastSquaresOptimizer >>> return incorrect values, when called from an instance of >>> org.apache.commons.math3.optimization.general.LevenbergMarquardtOptimizer >>> This has been broken (by me) during the clean-up of the latter, where I >>> failed to keep a (deprecated) "protected" field updated.[1] >>> [This mistake was not caught by the CM unit test suite...] >>> >>> I'll commit the fix and create a new tag. >>> >>> >>> Regards, >>> Gilles >>> >>> [1] Bitten by the equivalent of the "global" variables of old. :-{ >>> >>> >>> On Mon, Dec 17, 2012 at 09:41:48PM +0100, Gilles Sadowski wrote: >>>> Hi. >>>> >>>> Please have a look at the Commons Math 3.1 release candidate.[1] >>>> >>>> ---------- >>>> Tag: >>>> https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_1_RC2/ >>>> >>>> Site: >>>> http://people.apache.org/builds/commons/math/3.1/RC2/ >>>> >>>> Binaries: >>>> https://repository.apache.org/content/repositories/orgapachecommons-041/org/apache/commons/commons-math3/3.1/ >>>> >>>> [ ] +1 Release it. >>>> [ ] +0 Go ahead; I don't care. >>>> [ ] -0 There are a few minor glitches: ... >>>> [ ] -1 No, do not release it because ... >>>> >>>> This vote will close in 72 hours. >>>> ---------- >>>> >>>> >>>> Thanks, >>>> Gilles >>>> >>>> [1] This third attempt provides all the distribution files. The tag was >>>> unchanged (MATH_3_1_RC2). > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
