Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <496A08CF.50804@free.fr>
Date: Sun, 11 Jan 2009 15:57:19 +0100
From: Luc Maisonobe <Luc.Maisonobe@free.fr>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: [math] redesigning the optimization/estimation packages
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

The optimization/estimation packages extracted from Mantissa raise many
usability issues. There have been several questions last months asking
for examples on how to use them. The fast is these packages were
originally written for a probably too specific task and the public API
is not easy to understand.

Jira issue MATH-177 (http://issues.apache.org/jira/browse/MATH-177) is a
reminder for one aspect of the problem and a recent contribution from
Gilles Sadowski linked to another aspect was attached to it (Gilles
provided an implementation of the Brent minimization algorithm).

I would like to solve this globally for 2.0.

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. 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.

The third step would be to handle multivariate or multivalued functions.
Should separate parallel packages be created or not ? 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.

Does this make sense ?
Luc

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