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