You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Gilles (JIRA)" <ji...@apache.org> on 2011/07/15 15:05:59 UTC
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065905#comment-13065905 ]
Gilles commented on MATH-621:
-----------------------------
Oops, this is indeed FORTRAN code in Java clothes. There is quite _a lot_ of work to make it look like Java... :(
Personally, I'd rather not commit it as is, because it is unmaintainable (it does not match anything in CM in terms of design and programming style).
> BOBYQA is missing in optimization
> ---------------------------------
>
> Key: MATH-621
> URL: https://issues.apache.org/jira/browse/MATH-621
> Project: Commons Math
> Issue Type: New Feature
> Affects Versions: 3.0
> Reporter: Dr. Dietmar Wolz
> Fix For: 3.0
>
> Attachments: BOBYQA.math.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> During experiments with space flight trajectory optimizations I recently
> observed, that the direct optimization algorithm BOBYQA
> http://plato.asu.edu/ftp/other_software/bobyqa.zip
> from Mike Powell is significantly better than the simple Powell algorithm
> already in commons.math. It uses significantly lower function calls and is
> more reliable for high dimensional problems. You can replace CMA-ES in many
> more application cases by BOBYQA than by the simple Powell optimizer.
> I would like to contribute a Java port of the algorithm.
> I maintained the structure of the original FORTRAN code, so the
> code is fast but not very nice.
> License status: Michael Powell has sent the agreement via snail mail
> - it hasn't arrived yet.
> Progress: The attached patch relative to the trunk contains both the
> optimizer and the related unit tests - which are all green now.
> Performance:
> Performance difference (number of function evaluations)
> PowellOptimizer / BOBYQA for different test functions (taken from
> the unit test of BOBYQA, dimension=13 for most of the
> tests.
> Rosen = 9350 / 1283
> MinusElli = 118 / 59
> Elli = 223 / 58
> ElliRotated = 8626 / 1379
> Cigar = 353 / 60
> TwoAxes = 223 / 66
> CigTab = 362 / 60
> Sphere = 223 / 58
> Tablet = 223 / 58
> DiffPow = 421 / 928
> SsDiffPow = 614 / 219
> Ackley = 757 / 97
> Rastrigin = 340 / 64
> The number for DiffPow should be dicussed with Michael Powell,
> I will send him the details.
> Open Problems:
> Some checkstyle violations because of the original Fortran source:
> - Original method comments were copied - doesn't follow javadoc standard
> - Multiple variable declarations in one line as in the original source
> - Problems related to "goto" conversions:
> "gotos" not convertible in loops were transated into a finite automata (switch statement)
> "no default in switch"
> "fall through from previos case in switch"
> which usually are bad style make no sense here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (MATH-621) BOBYQA is missing in optimization
Posted by Dietmar Wolz <dr...@yahoo.de>.
Hi Luc, Gilles,
obviously I tend more in Lucs direction, although I understand Gilles
point of view. Specially since he is volunteering to invest time
to produce something maintainable. I will be on vacation from next
tuesday, so you can be sure there will be no overlapping work.
For sure I also tried to do this but decided to do a direct port first.
gotos are not only used for loops, but there is really a finite state
machine
logic in the code - together with a huge shared working storage accessed
via pointers. Since matlab-java ports are so much easier, I will also
have a look at BC-DFO as an alternative.
BOBYQA is currently used in the research as a reference, see for instance
www.cerfacs.fr/algor/reports/2010/TR_PA_10_70.pdf and
http://www.scielo.br/pdf/cam/v30n1/09.pdf. Commons.math users lived
without
it so far, but that doesn't mean that users in general don't use BOBYQA.
There are other open source libraries like
http://dlib.net/optimization.html
supporting it, and you can use this library via JNI from Java as I did.
Being accessible from commons.math can convince more users to switch to
Java and the standard optimization interface of commons math.
And I think we should honor one of the first pioneers of open source,
Mike Powell, founder of the Harwell Subroutine Library in 1964, one of
the first "Open Source" projects I ever heard of.
By the way, people are really using and modifying the original Fortran
code, see
http://www.scielo.br/pdf/cam/v30n1/09.pdf, something I wouldn't
recommend.
My best wishes for Gilles for his efforts to write a "clean" version.
>Hi Gilles,
>
>Le 15/07/2011 16:57, Gilles Sadowski a écrit :
>> Hello.
>>
>>>> Oops, this is indeed FORTRAN code in Java clothes. There is quite _a
>>>>lot_ of work to make it look like Java... :(
>>>> Personally, I'd rather not commit it as is, because it is
>>>>unmaintainable (it does not match anything in CM in terms of design
>>>>and programming style).
>>>
>>> Yes, but committing it this as is with an objective to "javaize" it
>>> would allow to:
>>>
>>> - have a reference test harness to check changes do not introduce
>>> regressions
>>> - allow non-committer to help by providing small patches instead
>>> of always reworking the complete code (Dietmar is not a committer
>>> yet)
>>> - allow monitor what changes are introduced slightly
>>> - avoid delaying to much the availability of the feature so most
>>> people can test it
>>> - avoid delaying release to much as once the API is fixed (and in
>>> fact it depends on the optimization framework which is already
>>> defined), the implementation can be changed afterwards in 3.1
>>>
>>> I agree the last point can lead to the code never been changed at
>>> all, but the other points are important too.
>>
>> The point of view of a maintainer will be that your last point will
>>swamp
>> any other considerations.
>> It is not consistent that we "nit-pick" some small pieces of code while
>>it
>> would be OK to commit that big scary one. [No offense to Dietmar, as
>>this
>> was an important first step: It is really invaluable to be able to run
>>the
>> tests as one is going through incremental changes.]
>>
>> I'm willing to start adapting the code. If there are other candidates,
>> that's fine too. But I certainly do not want to spend time converting it
>> while somebody else is working on overlapping changes.
>
>That's fine with me, I'll let you and Dietmar take care of this.
>
>>
>> It is understandable that people would be happy to play with a new toy.
>>But
>> they can also live without it (as they did until now) for some more
>>time.
>> [Or they can patch their local copy.]
>
>Yes, those who want to live on the bleeding edge are probably ready to
>put some effort in it.
>
>best regards,
>Luc
>
>>
>>
>> Best,
>> Gilles
>>
>
>
>---------------------------------------------------------------------
>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
Re: [jira] [Commented] (MATH-621) BOBYQA is missing in optimization
Posted by Luc Maisonobe <Lu...@free.fr>.
Hi Gilles,
Le 15/07/2011 16:57, Gilles Sadowski a écrit :
> Hello.
>
>>> Oops, this is indeed FORTRAN code in Java clothes. There is quite _a lot_ of work to make it look like Java... :(
>>> Personally, I'd rather not commit it as is, because it is unmaintainable (it does not match anything in CM in terms of design and programming style).
>>
>> Yes, but committing it this as is with an objective to "javaize" it
>> would allow to:
>>
>> - have a reference test harness to check changes do not introduce
>> regressions
>> - allow non-committer to help by providing small patches instead
>> of always reworking the complete code (Dietmar is not a committer
>> yet)
>> - allow monitor what changes are introduced slightly
>> - avoid delaying to much the availability of the feature so most
>> people can test it
>> - avoid delaying release to much as once the API is fixed (and in
>> fact it depends on the optimization framework which is already
>> defined), the implementation can be changed afterwards in 3.1
>>
>> I agree the last point can lead to the code never been changed at
>> all, but the other points are important too.
>
> The point of view of a maintainer will be that your last point will swamp
> any other considerations.
> It is not consistent that we "nit-pick" some small pieces of code while it
> would be OK to commit that big scary one. [No offense to Dietmar, as this
> was an important first step: It is really invaluable to be able to run the
> tests as one is going through incremental changes.]
>
> I'm willing to start adapting the code. If there are other candidates,
> that's fine too. But I certainly do not want to spend time converting it
> while somebody else is working on overlapping changes.
That's fine with me, I'll let you and Dietmar take care of this.
>
> It is understandable that people would be happy to play with a new toy. But
> they can also live without it (as they did until now) for some more time.
> [Or they can patch their local copy.]
Yes, those who want to live on the bleeding edge are probably ready to
put some effort in it.
best regards,
Luc
>
>
> Best,
> Gilles
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jira] [Commented] (MATH-621) BOBYQA is missing in optimization
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> >Oops, this is indeed FORTRAN code in Java clothes. There is quite _a lot_ of work to make it look like Java... :(
> >Personally, I'd rather not commit it as is, because it is unmaintainable (it does not match anything in CM in terms of design and programming style).
>
> Yes, but committing it this as is with an objective to "javaize" it
> would allow to:
>
> - have a reference test harness to check changes do not introduce
> regressions
> - allow non-committer to help by providing small patches instead
> of always reworking the complete code (Dietmar is not a committer
> yet)
> - allow monitor what changes are introduced slightly
> - avoid delaying to much the availability of the feature so most
> people can test it
> - avoid delaying release to much as once the API is fixed (and in
> fact it depends on the optimization framework which is already
> defined), the implementation can be changed afterwards in 3.1
>
> I agree the last point can lead to the code never been changed at
> all, but the other points are important too.
The point of view of a maintainer will be that your last point will swamp
any other considerations.
It is not consistent that we "nit-pick" some small pieces of code while it
would be OK to commit that big scary one. [No offense to Dietmar, as this
was an important first step: It is really invaluable to be able to run the
tests as one is going through incremental changes.]
I'm willing to start adapting the code. If there are other candidates,
that's fine too. But I certainly do not want to spend time converting it
while somebody else is working on overlapping changes.
It is understandable that people would be happy to play with a new toy. But
they can also live without it (as they did until now) for some more time.
[Or they can patch their local copy.]
Best,
Gilles
Re: [jira] [Commented] (MATH-621) BOBYQA is missing in optimization
Posted by Luc Maisonobe <Lu...@free.fr>.
Hi Gilles,
Le 15/07/2011 15:05, Gilles (JIRA) a écrit :
>
> [ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065905#comment-13065905 ]
>
> Gilles commented on MATH-621:
> -----------------------------
>
> Oops, this is indeed FORTRAN code in Java clothes. There is quite _a lot_ of work to make it look like Java... :(
> Personally, I'd rather not commit it as is, because it is unmaintainable (it does not match anything in CM in terms of design and programming style).
Yes, but committing it this as is with an objective to "javaize" it
would allow to:
- have a reference test harness to check changes do not introduce
regressions
- allow non-committer to help by providing small patches instead
of always reworking the complete code (Dietmar is not a committer
yet)
- allow monitor what changes are introduced slightly
- avoid delaying to much the availability of the feature so most
people can test it
- avoid delaying release to much as once the API is fixed (and in
fact it depends on the optimization framework which is already
defined), the implementation can be changed afterwards in 3.1
I agree the last point can lead to the code never been changed at all,
but the other points are important too.
best regards,
Luc
>
>
>> BOBYQA is missing in optimization
>> ---------------------------------
>>
>> Key: MATH-621
>> URL: https://issues.apache.org/jira/browse/MATH-621
>> Project: Commons Math
>> Issue Type: New Feature
>> Affects Versions: 3.0
>> Reporter: Dr. Dietmar Wolz
>> Fix For: 3.0
>>
>> Attachments: BOBYQA.math.patch
>>
>> Original Estimate: 8h
>> Remaining Estimate: 8h
>>
>> During experiments with space flight trajectory optimizations I recently
>> observed, that the direct optimization algorithm BOBYQA
>> http://plato.asu.edu/ftp/other_software/bobyqa.zip
>> from Mike Powell is significantly better than the simple Powell algorithm
>> already in commons.math. It uses significantly lower function calls and is
>> more reliable for high dimensional problems. You can replace CMA-ES in many
>> more application cases by BOBYQA than by the simple Powell optimizer.
>> I would like to contribute a Java port of the algorithm.
>> I maintained the structure of the original FORTRAN code, so the
>> code is fast but not very nice.
>> License status: Michael Powell has sent the agreement via snail mail
>> - it hasn't arrived yet.
>> Progress: The attached patch relative to the trunk contains both the
>> optimizer and the related unit tests - which are all green now.
>> Performance:
>> Performance difference (number of function evaluations)
>> PowellOptimizer / BOBYQA for different test functions (taken from
>> the unit test of BOBYQA, dimension=13 for most of the
>> tests.
>> Rosen = 9350 / 1283
>> MinusElli = 118 / 59
>> Elli = 223 / 58
>> ElliRotated = 8626 / 1379
>> Cigar = 353 / 60
>> TwoAxes = 223 / 66
>> CigTab = 362 / 60
>> Sphere = 223 / 58
>> Tablet = 223 / 58
>> DiffPow = 421 / 928
>> SsDiffPow = 614 / 219
>> Ackley = 757 / 97
>> Rastrigin = 340 / 64
>> The number for DiffPow should be dicussed with Michael Powell,
>> I will send him the details.
>> Open Problems:
>> Some checkstyle violations because of the original Fortran source:
>> - Original method comments were copied - doesn't follow javadoc standard
>> - Multiple variable declarations in one line as in the original source
>> - Problems related to "goto" conversions:
>> "gotos" not convertible in loops were transated into a finite automata (switch statement)
>> "no default in switch"
>> "fall through from previos case in switch"
>> which usually are bad style make no sense here.
>
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>