commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dietmar Wolz <>
Subject Re: [jira] [Commented] (MATH-621) BOBYQA is missing in optimization
Date Fri, 15 Jul 2011 18:10:31 GMT
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
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 and Commons.math users lived
it so far, but that doesn't mean that users in general don't use BOBYQA.
There are other open source libraries like
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, something I wouldn't

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
>> any other considerations.
>> It is not consistent that we "nit-pick" some small pieces of code while
>> would be OK to commit that big scary one. [No offense to Dietmar, as
>> was an important first step: It is really invaluable to be able to run
>> 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.
>> they can also live without it (as they did until now) for some more
>> [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,
>> Best,
>> Gilles
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message