commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Berlin <kber...@gmail.com>
Subject Re: [Math] Comments on the new "optim" API (Was: [CANCEL][VOTE] ...)
Date Tue, 18 Dec 2012 19:21:06 GMT
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 <gilles@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 <gilles@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message