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-unsubscr...@commons.apache.org >For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
