You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles Sadowski <gi...@harfang.homelinux.org> on 2012/12/17 21:41:48 UTC
[VOTE] Release Commons Math 3.1 (take 3)
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
Re: [Math] Comments on the new "optim" API
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Tue, Dec 18, 2012 at 02:21:06PM -0500, Konstantin Berlin wrote:
> 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.
Please review the discussion (on the bug tracking system and on the ML)
about the inclusion of "BOBYQAOptimizer".
We have a code that, IMO, should not be there, because it is not
maintainable by the current contributors.
If you want to change this unfortunate situation, you are most welcome to
help, by providing code patches. Without "hacks" please. :-)
Regards,
Gilles
> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Comments on the new "optim" API (Was: [CANCEL][VOTE] ...)
Posted by Konstantin Berlin <kb...@gmail.com>.
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 <gi...@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 <gi...@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
[Math] Comments on the new "optim" API (Was: [CANCEL][VOTE] ...)
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
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 <gi...@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
Re: [CANCEL][VOTE] Release Commons Math 3.1 (take 3)
Posted by Konstantin Berlin <kb...@gmail.com>.
-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.
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.
On Dec 18, 2012, at 12:49 PM, Gilles Sadowski <gi...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[CANCEL][VOTE] Release Commons Math 3.1 (take 3)
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
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