commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [math] redesigning the optimization/estimation packages
Date Thu, 15 Jan 2009 11:31:00 GMT
Hello.

> I agree with code reuse, though. Perhaps we could have a very generic
> superinterface for the shared parts like convergence settings or max
> iterations and things like that. But the "solve" methods should be
> separate, and even probably have different names to stay on the safe side.
>
> > [...]
> 
> I would prefer something like:
> 
>  public interface ConvergenceAlgorithm {
>     void setMaximalIterationCount(int count);
>     ...
>  }
> 
>  public interface UnivariateRealSolver extends ConvergenceAlgorithm {
>     double solve(UnivariateRealFunction f, ...);
>  }
> 
>  public interface UnivariateRealMinimizer extends ConvergenceAlgorithm {
>     double findMinimum(UnivariateRealFunction f, ...);
>  }

Agreed.

> > [...] it will be much more work to
> > refactor the framework for the multi-dimensional case, whereas the packages
> > in the one-dimensional case could be "stabilized" sooner.
> 
> You are right, but we cannot postpone major change after 2.0. Once 2.0
> will be out, we will try as much as possible to preserve compatibility
> for users, so later major change would have to wait for 3.0. Now is
> proper time to revamp everything we need.

That's certainly fine with me.
[I didn't mean to delay the refactoring, just that the packages for the one-
and for the multi-dimensional cases should preferably be separate.]

> I expect to have almost one month off work next month due to forced rest
> after minor surgery operation. I will have plenty of time to kill then.

Good luck, and best wishes for the recovery.

> > We already use several librairies: "jMinuit" in Java and "Opt++" in C++
> > (using JNI). Surely I'd prefer everything to be in Commons-Math...
> 
> Our current optimization part is still fairly basic, so for now it would
> be safe to stay with those libraries. What is implemented does work and
> works well, but there are not many algorithms and the API organization
> is really awkward for now. Improving the organization to have a stable
> framework is a goal for 2.0. Adding new algorithms and features to
> become a decent alternative to these libraries is a goal for 2.x, except
> if new motivated contributors step in ...

Our project needs an efficient (most importantly with a minimal number of
calls to the evaluation function) multi-dimensional optimizer, and several
alternatives must be tested, so you can count me in for helping with the
Java implementation.

Best,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message