commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dietmar Wolz <drdietmarw...@yahoo.de>
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
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


Mime
View raw message