Hi.
> The first step would be to rearrange slightly the analysis package. We
> could have the main interfaces in the analysis package
> (UnivariateRealFunction, DifferentiableUnivariateRealFunction ...) and
> spread the other interfaces and classes in several subpackages:
> - analysis.solving
> - analysis.integration
> - analysis.interpolation
>
> The second step would be to add an analysis.minimization package. The
> contributed Brent minimization would get there, probably with a simple
> gold section minimizer too.
Could we have "root" instead of "solving"?
Also we could have "minimum" instead of "minimization".
I think that "root" is clearer (e.g. for a new user browsing the package
list javadoc).
[And both are little bit shorter names than the alternative. ;-)]
> I think a dedicated interface
> UnivariateRealMinimizer would be needed instead of reusing the
> UnivariateRealSolver one, both interface have different goals. They
> probably share many methods but not the underlying semantics.
I'd rather re-use as much code as possible.
Which methods do not have the same semantics? The "getResult" method, for
example, can return a root location as well as a minimum location.
What about creating new interfaces and classes in the future "minimization"
(or "minimum") package that would extend those in "solving" (or "root")?
public interface UnivariateRealMinimizer extends UnivariateRealSolver {
public double getValueAtMinimum();
}
public class UnivariateRealMinimizerImpl extends UnivariateRealSolverImpl
implements UnivariateRealMinimizer {
private double valueAtMinimum;
protected void setResult(double x,
double fx,
double iterationCount) {
setResult(x, iterationCount);
valueAtMinimum = fx;
}
public double getValueAtMinimum() {
return valueAtMinimum;
}
}
> The third step would be to handle multivariate or multivalued functions.
> Should separate parallel packages be created or not ?
>From a practical point of view, I'd think so: I'd guess that it is more
common to use the univariate algorithms, and so, it would be convenient not
to clutter those packages with classes that are useful only in the
multi-dimensional case.
Also, from what you say below, it seems that 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.
> The minimization
> part for these kind of functions would come from the low level classes
> of the estimation package and from the optimization package. The former
> ones correspond to algorithms using derivatives and the latter
> correspond to algorithms using only function values. The interfaces
> should be simplified to remain low-level and deal directly with function
> values, target, residuals.
>
> A fourth step would be to build higher level abstractions on top of the
> previous ones, providing the concepts of measurements, parameters and
> linear/non-linear model ... These are mainly the existing
> WeightedMeasurement, EstimatedParameter and EstimationProblem classes
> and interfaces.
We already use several librairies: "jMinuit" in Java and "Opt++" in C++
(using JNI). Surely I'd prefer everything to be in Commons-Math...
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
