Re: [Math] Remove "BOBYQAOptimizer"

2013-01-02 Thread Dietmar Wolz
>If nobody is able to work on "BOBYQAOptimizer" so as to make it a >maintainable and documented code, I request that it be removed from the next >major release (4.0). No objections from my side. BOBYQA was again heavily used at  https://issfd.jpl.nasa.gov/home/GTOC6 (10th place this time), but 

AW: [math] CMA-ES input sigma

2011-11-07 Thread Dr. Dietmar Wolz
Will have a look when Gilles finished the change next week. Dietmar -Ursprüngliche Nachricht- Von: Gilles Sadowski [mailto:gil...@harfang.homelinux.org] Gesendet: Montag, 7. November 2011 15:22 An: dev@commons.apache.org Betreff: Re: [math] CMA-ES input sigma > [...] > > > > P.S. Pleas

Re: [Math] Optimizers: API for simple bound constraints

2011-10-27 Thread Dietmar Wolz
+1 also valid for CMA-ES

Re: [math] BOBYQA

2011-07-18 Thread Dietmar Wolz
> >This would be great too. Maybe I could get some contacts with Serge >Gratton. Cerfacs is in Toulouse and I know for sure many people who have >direct contact with him. I even think he was present at the same small >seminar we attended together when you and Nikolaus presented your work >on CMA-E

Re: [jira] [Commented] (MATH-621) BOBYQA is missing in optimization

2011-07-15 Thread Dietmar Wolz
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 tr

Re: [math] BOBYQA

2011-07-14 Thread Dietmar Wolz
Indeed it was not easy to get the thing converted. I will apply all the tests I already wrote for CMA-ES (they could be refactored out in a separate class later). The last two bugs I detected resulted only in a slight performance decrease and were only detected by debugging both programs in paralle

AW: [math] BOBYQA

2011-07-14 Thread Dr. Dietmar Wolz
Here is the letter from the Autor which I received yesterday. There seems to be no problem regarding a signed agreement. I will send him our conversation, so you can get directly in contact. "Dear Dr Wolz, Many thanks for your e-mail. I was delighted to hear of your interest in BOBYQA and

[math] BOBYQA

2011-07-13 Thread Dietmar Wolz
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 significant

AW: [math] [GUMP@vmgump]: Project commons-math (in module apache-commons) failed

2011-05-16 Thread Dr. Dietmar Wolz
> In fact, I've only ever seen "testMaximize" and (less often) "testRosen" > fail. So, for the time being, I'd add "@Retry" to those only. +1 for adding @Retry to the two tests occasionally failing - To unsubscribe, e-mail: de

AW: [math] [GUMP@vmgump]: Project commons-math (in module apache-commons) failed

2011-05-16 Thread Dr. Dietmar Wolz
Nikolaus Hansen, Luc and me discussed this issue in Toulouse. We have two options to handle this kind of failure in tests of stochastic optimization algorithms: 1) fixed random seed - but this reduces the value of the test 2) Using the RetryRunner - preferred solution @Retry(3) should be suffici

AW: [math] CMA-ES optimization algorithm

2010-11-26 Thread Dr. Dietmar Wolz
>However, can we slow down on the new features? (Am I saying this? ;-)) [We previously agreed that the main algorithm code should be put in place before >any other bells and whistles.] We didn't discuss when a possible enhancement of MultiStartMultivariateRealOptimizer will be implemented, just w

AW: [math] CMA-ES optimization algorithm

2010-11-26 Thread Dr. Dietmar Wolz
>Should we simply allow user to register an instance of some optimizer reconfigurator interface in the constructor ? Something like: > > public MultiStartDifferentiableMultivariateVectorialOptimizer( > DifferentiableMultivariateVectorialOptimizer optimizer, > int starts, >

RE: [math] CMA-ES optimization algorithm

2010-11-26 Thread Dr. Dietmar Wolz
There is another topic worth mentioning: Multi-start using MultiStartMultivariateRealOptimizer. In http://www.lri.fr/~hansen/cec2005.html an algo called G-CMA-ES performed very well: A CMA evolution strategy restarted with increasing population size. Is there a general need beside CMA-ES to modi

AW: [math] roadmap for 2.X and 3.0 ?

2010-11-24 Thread Dietmar Wolz
>that depends on math 2.1. Orekit itself (or whatever other immediate >dependency) may not have cut a release changing its internal use to 3.0. At Is this realistic? I would expect quite early an Orekit version supporting CM 3.0. May be not a release but the actual Orekit trunk. So for your o

AW: [math] roadmap for 2.X and 3.0 ?

2010-11-24 Thread Dietmar Wolz
>The name change is not for maintaining several versions in parallel. It >is to allow projects to have parts depending on the old (unmaintained) >version and new (maintained) version to compile and let them go back in >sync progressively. It is exactly the same process than the change in >2.2 for

AW: [math] CMA-ES optimization algorithm

2010-11-23 Thread Dietmar Wolz
>> Yes, we can start with a bare implementation and add the bells and >> whistles afterwards. In this case, they could also be integrated to the >> other optimization algorithms if something general enough is found. >+1 As soon as Nikolaus review is finished I will prepare the patch. Unit tests

AW: [math] CMA-ES optimization algorithm

2010-11-23 Thread Dietmar Wolz
>> >> And an iterative algorithm that implements "HandlerSetter" will call >> "update" after each iteration. >Yes, this is the way user can monitor what he wants. Perhaps with a few >set of more specialized handlers, the signature of the update method >could be adapted for the algorithm type (i

AW: [math] CMA-ES optimization algorithm

2010-11-22 Thread Dr. Dietmar Wolz
>There is something loosely similar to what you need in the ODE packages. >This kind of algorithms also need some information to be provided back to >users during the algorithm run. For ODE solvers, it is at the end of each >integration step. >We have set this with a StepHandler interface. If t

AW: [math] CMA-ES optimization algorithm

2010-11-19 Thread Dr. Dietmar Wolz
>I really don't think that a general progress listener framework implies this >clutter and for long running algorithms is a very nice thing. CM does not >actually have all that many long running algorithms. >On the other hand, the proposed interface is not a general progress listener >and is n

AW: [math] CMA-ES optimization algorithm

2010-11-18 Thread Dr. Dietmar Wolz
>The problem is that we would again be re-inventing some wheel which IMHO doesn't belong to a low-level math library such as CM. >A basic logging interface already exists: It's "slf4j". slf4j and the interface I had in mind are completely different things. slf4j is a generic logging interface mea

RE: [math] CMA-ES optimization algorithm

2010-11-18 Thread Dietmar Wolz
>Did you use the "MATH_2_X" or the "trunk" repository? I think "MATH_2_X", but will test with trunk. I think the patch should be against trunk? >> modifiable. Should we create an additional interface extending >> MultivariateRealOptimizer which covers this aspect? >No. >All the parameters must

[math] CMA-ES optimization algorithm

2010-11-18 Thread Dietmar Wolz
A new Jira issue was recently created https://issues.apache.org/jira/browse/MATH-442 regarding the contribution of a new optimization algorithm CMA-ES. Recently I implemented the optimization algorithm CMA-ES based on org.apache.commons.math.linear and used it for